Accessibility Checking for Large Sites

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.

Not all ARIA role-attribute combinations are valid. This rule ensures that each role has the required qualities.

Using ARIA attributes in roles where they are not permitted can impair web page accessibility. Using an improper role-attribute combination will have no effect on application accessibility at best and may trigger behavior that blocks accessibility for entire areas of an application at worst.

When ARIA attributes are used on HTML elements that do not conform to WAI-ARIA 1.1, they interfere with the semantics of the elements, causing assistive technology products to display nonsensical user interface (UI) information that does not represent the document’s true UI.

What this Accessibility Rule Checks

Checks that each element with an ARIA role is using only the ARIA attributes that are permitted for that role.

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.

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.

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.

For screen reader users, aria meter elements must have legible language that defines the destination, function, or action.

Users of screen readers are unable to determine the function of items with role="meter" but no accessible name.

What this Accessibility Rule Checks

Checks that all items with role="meter" have a distinguishable, accessible name.

For screen reader users, Aria progressbar items must include understandable language that specifies the destination, purpose, or action.

Users of screen readers are unable to determine the purpose of items with the role="progressbar" attribute that lack an accessible name.

What this Accessibility Rule Checks

Checks that all items with role="progressbar" have a distinguishable, accessible name.

Ensures that the aria-roledescription attribute is only applied to elements having explicit or implicit role values.

Inappropriate aria-roledescription attribute values that clash with an element’s implicit or explicit role value can impede the web page’s accessibility. A contradictory aria-roledescription attribute value may have no effect on the application’s accessibility and may trigger behavior that blocks accessibility for entire application sections.

When aria-roledescription attributes are applied to HTML elements not in accordance with WAI-ARIA 1.1, a semantic conflict may occur between the aria-roledescription value and the implicit or explicit element role value, resulting in assistive technology products reporting nonsensical user interface (UI) information that does not accurately represent the intended UI experience.

What this Accessibility Rule Checks

Use aria-roledescription values to adequately explain implicit or explicit element role values.

ARIA role values must be assigned valid values. Role values must be appropriately written, correlate to existing ARIA role values, and not be abstract roles in order to correctly display the element’s purpose.

Assistive technologies do not read elements with erroneous ARIA role values as intended by the developer.

When screen readers and other assistive devices do not know the function of each element on a web page, they are unable to interact with or communicate the function to the user. When a role value is invalid, an element’s characteristics, properties, and ways of transmitting information to and/or from the user can be communicated via assistive technologies.

What this Accessibility Rule Checks

Examines each element containing the WAI-ARIA role property to check that its value is valid.