Navigate through the boxes below where each delineates a distinct feature or test script designed for comprehensive web accessibility testing. Click "Go To Testing Page" within each section to explore its functionalities, integrated capabilities, and detailed guidelines to enhance your testing experience.
Use the search box below to search through the 55 different web accessibility testing scripts.
Type to filter the cards below:
Access keys let users quickly focus a part of the page. For proper navigation, each access key must be unique. Learn more about access keys
View Generated Reports Go To Testing PageInformative elements should aim for short, descriptive alternate text. Decorative elements can be ignored with an empty alt attribute. Learn more about the `alt` attribute
View Generated Reports Go To Testing PageEach ARIA `role` supports a specific subset of `aria-*` attributes. Mismatching these invalidates the `aria-*` attributes. Learn how to match ARIA attributes to their roles
View Generated Reports Go To Testing PageWhen an element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. Learn how to make command elements more accessible
View Generated Reports Go To Testing Page
Assistive technologies, like screen readers, work inconsistently when
aria-hidden="true" is set on the document <body>. Learn how
`aria-hidden` affects the document body
Focusable descendents within an <aria-hidden="true"> element
prevent those
interactive elements from being available to users of assistive technologies like
screen readers. Learn how
`aria-hidden` affects focusable elements
When an input field doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. Learn more about input field labels
View Generated Reports Go To Testing PageWhen a meter element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. Learn how to name `meter` elements
View Generated Reports Go To Testing Page
When a <progressbar> element doesn't have an accessible name,
screen
readers announce it with a generic name, making it unusable for users who rely on
screen readers. Learn how
to label `progressbar` elements
Some ARIA roles have required attributes that describe the state of the element to screen readers. Learn more about roles and required attributes
View Generated Reports Go To Testing PageSome ARIA parent roles must contain specific child roles to perform their intended accessibility functions. Learn more about roles and required children elements
View Generated Reports Go To Testing PageSome ARIA child roles must be contained by specific parent roles to properly perform their intended accessibility functions. Learn more about ARIA roles and required parent element
View Generated Reports Go To Testing PageARIA roles must have valid values in order to perform their intended accessibility functions. Learn more about valid ARIA roles
View Generated Reports Go To Testing PageWhen a toggle field doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. Learn more about toggle fields
View Generated Reports Go To Testing PageWhen a tooltip element doesn't have an accessible name, screen readers announce it with a generic name, making it unusable for users who rely on screen readers. Learn how to name `tooltip` elements
View Generated Reports Go To Testing Page
When a <treeitem> element doesn't have an accessible name, screen
readers announce it with a generic name, making it unusable for users who rely on
screen readers. Learn more
about labeling `treeitem` elements
Assistive technologies, like screen readers, can't interpret ARIA attributes with invalid names. Learn more about valid ARIA attributes
View Generated Reports Go To Testing PageAssistive technologies, like screen readers, can't interpret ARIA attributes with invalid values. Learn more about valid values for ARIA attributes
View Generated Reports Go To Testing PageWhen a button doesn't have an accessible name, screen readers announce it as "button", making it unusable for users who rely on screen readers. Learn how to make buttons more accessible
View Generated Reports Go To Testing PageAdding ways to bypass repetitive content lets keyboard users navigate the page more efficiently. Learn more about bypass blocks
View Generated Reports Go To Testing PageLow-contrast text is difficult or impossible for many users to read. Learn how to provide sufficient color contrast
View Generated Reports Go To Testing PageCustom interactive controls have associated labels, provided by aria-label or aria-labelledby. Learn more about custom controls and labels
View Generated Reports Go To Testing PageCustom interactive controls have appropriate ARIA roles. Learn how to add roles to custom controls
View Generated Reports Go To Testing PageWhen definition lists are not properly marked up, screen readers may produce confusing or inaccurate output. Learn how to structure definition lists correctly
View Generated Reports Go To Testing Page
Definition list items (<dt> and <dd>) must be
wrapped in a parent <dl> element to ensure that screen readers
can properly announce them. Learn
how to structure definition lists correctly
The title gives screen reader users an overview of the page, and search engine users rely on it heavily to determine if a page is relevant to their search. Learn more about document titles
View Generated Reports Go To Testing PageAll focusable elements must have a unique `id` to ensure that they're visible to assistive technologies. Learn how to fix duplicate `id`s
View Generated Reports Go To Testing PageThe value of an ARIA ID must be unique to prevent other instances from being overlooked by assistive technologies. Learn how to fix duplicate ARIA IDs
View Generated Reports Go To Testing PageA user can tab into and out of any control or region without accidentally trapping their focus. Learn how to avoid focus traps
View Generated Reports Go To Testing PageCustom interactive controls are keyboard focusable and display a focus indicator. Learn how to make custom controls focusable
View Generated Reports Go To Testing PageForm fields with multiple labels can be confusingly announced by assistive technologies like screen readers which use either the first, the last, or all of the labels. Learn how to use form labels
View Generated Reports Go To Testing PageScreen reader users rely on frame titles to describe the contents of frames. Learn more about frame titles
View Generated Reports Go To Testing PageProperly ordered headings that do not skip levels convey the semantic structure of the page, making it easier to navigate and understand when using assistive technologies. Learn more about heading order
View Generated Reports Go To Testing PageIf a page doesn't specify a `lang` attribute, a screen reader assumes that the page is in the default language that the user chose when setting up the screen reader. If the page isn't actually in the default language, then the screen reader might not announce the page's text correctly. Learn more about the `lang` attribute
View Generated Reports Go To Testing PageSpecifying a valid BCP 47 language helps screen readers announce text properly. Learn how to use the `lang` attribute
View Generated Reports Go To Testing Page
When an image is being used as an <input> button, providing
alternative text can help screen reader users understand the purpose of the button.
Learn about
input image alt text
Interactive elements, such as links and buttons, should indicate their state and be distinguishable from non-interactive elements. Learn how to decorate interactive elements with affordance hints
View Generated Reports Go To Testing PageLabels ensure that form controls are announced properly by assistive technologies, like screen readers. Learn more about form element labels
View Generated Reports Go To Testing PageLink text (and alternate text for images, when used as links) that is discernible, unique, and focusable improves the navigation experience for screen reader users. Learn how to make links accessible
View Generated Reports Go To Testing PageScreen readers have a specific way of announcing lists. Ensuring proper list structure aids screen reader output. Learn more about proper list structure
View Generated Reports Go To Testing Page
Screen readers require list items (<li>) to be contained within a
parent
<ul>, <ol> or <menu>` to be
announced properly. Learn more about
proper list structure
Tabbing through the page follows the visual layout. Users cannot focus elements that are offscreen. Learn more about logical tab ordering
View Generated Reports Go To Testing PageIf new content, such as a dialog, is added to the page, the user's focus is directed to it. Learn how to direct focus to new content
View Generated Reports Go To Testing PageUsers do not expect a page to refresh automatically, and doing so will move focus back to the top of the page. This may create a frustrating or confusing experience.
View Generated Reports Go To Testing PageScreen readers have features to make navigating tables easier. Ensuring `
Access keys let users quickly focus a part of the page. For proper navigation, each access key must be unique. Learn more about access keys
View Generated Reports Go To Testing PageDisabling zooming is problematic for users with low vision who rely on screen magnification to properly see the contents of a web page. Learn more about the viewport meta tag
View Generated Reports Go To Testing PageA value greater than 0 implies an explicit navigation ordering. Although technically valid, this often creates frustrating experiences for users who rely on assistive technologies. Learn more about the `tabindex` attribute
View Generated Reports Go To Testing PageScreen readers have features to make navigating tables easier. Ensuring `
Screen readers have features to make navigating tables easier. Ensuring table headers always refer to some set of cells may improve the experience for screen reader users. Learn more about table headers
View Generated Reports Go To Testing Page
Landmark elements (<main>, <nav>, etc.) are
used to improve the keyboard navigation of the page for assistive technology. Learn
more about landmark elements
Specifying a valid BCP 47 language on elements helps ensure that text is pronounced correctly by a screen reader. Learn how to use the `lang` attribute
View Generated Reports Go To Testing PageWhen a video provides a caption it is easier for deaf and hearing impaired users to access its information. Learn more about video captions
View Generated Reports Go To Testing PageDOM order matches the visual order, improving navigation for assistive technology. Learn more about DOM and visual ordering
View Generated Reports Go To Testing PageDisabling zooming is problematic for users with low vision who rely on screen magnification to properly see the contents of a web page. Learn more about the viewport meta tag
View Generated Reports Go To Testing PageDisabling zooming is problematic for users with low vision who rely on screen magnification to properly see the contents of a web page. Learn more about the viewport meta tag
View Generated Reports Go To Testing Page
Screen readers cannot translate non-text content. Adding alternate text to <object> elements helps screen readers convey meaning to users.
Learn more about alt text for `object` elements
Offscreen content is hidden with display: none or
<aria-hidden=true.> Learn how to properly hide offscreen content