role='text' should have no focusable descendants

A document’s accesskey attribute values must all be distinct. Or, to put it another way, accesskeys must not be used more than once to protect keyboard users from unpleasant surprises.

When a document’s accesskey attribute value is supplied, users can quickly activate or switch the focus to a particular element by hitting the designated key (often in tandem with the alt key). The page becomes less accessible as a result of duplicating the values for the accesskey attribute.

Make sure the value of each defined accesskey is distinct and does not interfere with any screen reader or default browser shortcut keys.

Users who must use alternative keyboards or input devices serving as keyboard emulators, users who have problems tracking a pointer, or users who are blind or have low eyesight and cannot employ eye-hand coordination-required devices like mice, cannot operate the content.

What this Accessibility Rule Checks

Makes certain that every element on the page with an accesskey attribute has a different value.

For screen reader users, Aria dialog items must include intelligible language that specifies the destination, purpose, function, or action in detail.

Elements with role="dialog" or role="alertdialog" that lack an accessible name cannot be understood by screen reader users.

What this Accessibility Rule Checks

Verifies that all objects with the role="dialog" or role="alertdialog" attribute have a clear, understandable name.

The destination, purpose, function, or action of an Aria treeitem element must be made clear in the element’s understandable text for screen reader users.

Users of screen readers are unable to determine the function of items with the role treeitem that lack an accessible name.

What this Accessibility Rule Checks

Ensures that all objects with the role treeitem have a clear, understandable name.

Using the title or aria-describedby properties, form <input> elements may be given titles (but not both). The purpose of these qualities is to convey more information, such as a tip.

These properties are used to convey additional information, such as a hint. Hints are exposed differently to accessibility APIs than labels, which can cause issues with assistive technologies.

When form inputs such as text entry fields, radio buttons, check boxes, and select menus do not have labels other than the title and aria-describedby attribute values, screen readers perceive the material as advisory only. The labels provided by the title and aria-describedby attributes are insufficient to create a real label that can be inferred programmatically from the input form element’s code.

What this Accessibility Rule Checks

Ensures that every <input> that requires a label has a label other than title or aria-describedby.

To avoid an unexpected tab order that would appear to miss some components entirely, a tabindex attribute must never have a value greater than 0.

tabindex usage with a value larger than 0 can lead to just as many issues as it fixes. The unusual tab order makes the website less logical and may give the impression that some elements have been completely skipped.

The following are some issues that tabindex (with a value of 1 or above) results in:

• Unexpected tab order: From the user’s perspective, tabindex alters the normal tab order in unanticipated ways, which could lead to confusion.

• Items can appear to be skipped entirely: Items only once appear in the tab sequence. When a user navigates through the tabindex items and moves on to the rest of the page, they eventually reach the location of the tabindex items. However, the tabbing cycle skips over these links because the user already navigated past them at the start of the cycle. When visitors are unable to access items and may be unaware that they must cycle through the complete collection of links on the page to reaccess those links, incorrect tab ordering are frustrating.

• All tabindex items are tabbed to before any non-tabindex items. You would need to set the tabindex value for each and every item through the end of the updated section if you wanted to modify the tab order of the initial items AND of a section further down the page. When taken to an extreme, if a page contains 20 links and one of those links has its tabindex set to tabindex="100", the user will tab to that link first even if there are fewer than 100 links on the page. The tab order of sections further down the page cannot be changed unless all the links before that section’s tab order are manually changed.

What this Accessibility Rule Checks

Makes sure that explicit tabindex attributes that are greater than 0 are never used

WAI-ARIA role attribute values must be correct. This means that values must be written correctly, correlate to existing ARIA role values, and not be abstract roles in order to properly display the element’s purpose.

When an assigned WAI-ARIA role value for the parent element is invalid, a developer’s intended accessible technology activity is disabled.

When screen readers and other assistive devices do not understand the job of each element on a web page, they cannot interact with it intelligently or explain the role to the user. When the value for a role is invalid, assistive technologies are unable to communicate the element’s features, properties, and methods. Applying role="table" to a <ul>, for example, effectively hijacks the default semantics associated with the <ul> element in a way that screenreaders do not expect, resulting in unexpected behavior.

What this Accessibility Rule Checks

Check all elements with WAI-ARIA role attribute values to confirm the role value is correct. The role value must be appropriate for the element in the context of the document.

The destination, purpose, function, or action of an ARIA command element must be made clear in understandable text for screen reader users.

The function of items with the roles link, button, or menuitem that lack an accessible name cannot be understood by screen reader users.

What this Accessibility Rule Checks

Verifies that all elements with the roles link, button, or menuitem have a clear, understandable name.

ARIA attributes must be used as specified for the element’s role.

Using ARIA attributes on elements where they are not expected can result in unpredictable behavior for assistive technologies. This can lead to a poor user experience for people with disabilities who rely on these technologies. It is important to follow the ARIA specification to ensure that assistive technologies can properly interpret and communicate the intended meaning of the content.

Some ARIA attributes are only allowed on an element under certain conditions. Different attributes have different limitations to them:

aria-checked: This should not be used on an HTML input element with type=”checkbox”. Such elements have a checked state determined by the browser. Browsers should ignore aria-checked in this scenario. Because browsers do this inconsistently, a difference between the native checkbox state and the aria-checked value will result in differences between screen readers and other assistive technologies.

The aria-posinset, aria-setsize, aria-expanded, and aria-level attributes are conditional when used on a row. This can be either tr element, or an element with role="row". These attributes can only be used when the row is part of treegrid. When used inside a table or grid, these attributes have no function, and could result in unpredictable behavior from screen readers and other assistive technologies.

What this Accessibility Rule Checks

Check that ARIA attributes are not used in a way that their role describes authors should not, or must not do. I.e the use of this ARIA attribute is conditional.

This rule determines whether or not aria-hidden elements contain focusable elements.

Using the property aria-hidden="true" on an element removes the element and all of its child nodes from the accessibility API, rendering the element fully unavailable to screen readers and other assistive technology.

aria-hidden may be used with extreme discretion to hide visibly displayed content from assistive technologies if the act of hiding this content is meant to enhance the experience of assistive technology users by reducing redundant or superfluous content.

If aria-hidden is employed to hide material from screen readers, the same or equal meaning and functionality must be made available to assistive technologies.

Using aria-hidden="false" on content that is a descendant of an element that is hidden using aria-hidden="true" will not reveal that content to the accessibility API, nor will it be accessible to screen readers or other assistive technology.

The rule applies to any element whose aria-hidden attribute value is true.

By adding aria-hidden="true" to an element, authors assure that assistive technologies will disregard the element. This can be used to hide aesthetic elements, such as icon typefaces, that are not intended to be read by assistive technologies.

A focusable element with aria-hidden="true" is disregarded as part of the reading order, but is still part of the focus order, making it unclear if it is visible or hidden.

What this Accessibility Rule Checks

For all user interface components, including form elements, links, and script-generated components, the name and role can be identified programmatically; user-specified states, properties, and values can be set programmatically; and user agents, including assistive technologies, are notified of changes.

Ensures every ARIA input field has an accessible name.

This rule ensures that each ARIA input field has a name that is accessible.

There must be accessible names for the following input field roles:

• combobox
• listbox
• searchbox
• slider
• spinbutton
• textbox

What this Accessibility Rule Checks

The names of ARIA input fields must be accessible.