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.

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.

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.

No focusable children are allowed on elements with the role="text" attribute.

When a text node is split by markup (for example, <h1>Good morning, <span>friend</span></h1>) VoiceOver will treat it as two distinct phrases rather than one. Adding role="text" to the elements circumvents the issue.

In addition, it overrides the role of the element and its descendants, treating them as text nodes. If one of the descendant items is also focusable, an empty tab stop will be generated. That is, you might tab to the element but VoiceOver would not announce its name, role, or value.

What this Accessibility Rule Checks

Checks each element with the role="text" attribute to guarantee that none of its children are focusable.

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.

It is a best practice to make sure each heading element, denoted by the tags <h1> through <h6>, contains text.

Users of screen readers are informed when a heading tag is present. Users may become confused or even unable to access information on the page’s structure if the headline is blank or the text cannot be accessible.

Users of this technology won’t be able to hear the content of a header if the text inside it is inaccessible to a screen reader. Users using screen readers must be able to access the contents since headings reveal the structure of a webpage.

Applying header markup (<h1> through <h6>) is a quick approach to make content stand out, but doing so will make it more difficult for those using assistive technology to navigate a website.

Due to the fact that search engines use headings when filtering, arranging, and showing results, headers offer advantages beyond just making a page more accessible. Making your website more searchable is another benefit of making it more accessible.

Users of screen readers can navigate between headings in the same manner that sighted users might skim a page to gain a sense of its contents. Users, especially those who use screen readers, can save a ton of time and stress by using well-written, logically-arranged headings.

What this Accessibility Rule Checks

Ensures that headings have content and that a screen reader can access that content.

The text in table header components should be visible. Make sure screen reader users can access the table header. It is preferable to mark up an element with a td if it is not a header.

Both sighted users and screen reader users should be able to comprehend the visible text that explains the purpose of the row or column in table header components.

What this Accessibility Rule Checks

Verifies that each table header element has a visible text.

Whether native HTML or a custom widget, user input elements need to play the right roles in order to make their meaning clear to screen reader users when they are focused on and landed on. If a custom widget, the element’s function must be correctly exposed by using appropriate ARIA role values rather than abstract roles.

In order for screen reader technology to convey information to users, elements in the focus order must play a function appropriate for interactive content.

If interactive content elements do not have the proper roles, the developer’s planned accessibility function cannot be carried out by the role.

When screen readers and other assistive technologies cannot communicate to the user the proper role of each element on the web page, they are unable to interact with it sensibly. Assistive technology cannot communicate with an HTML element’s set of features, properties, and ways of communicating information to and/or from the user when the value for a role is invalid.

What this Accessibility Rule Checks

Verifies that the role attribute value is accurate and suitable for all interactive components in the focus order, regardless of whether they are native HTML or customized ARIA widgets.

Tests with axe-core are required for frames.

The tool cannot do violation testing on numerous levels of nested iframes without the axe-core script.

What this Accessibility Rule Checks

Axe is instructed to run within iframes when the iframes property is set to true. This checks for the axe-core script to deliver a “review item” result using both frame and iframe selectors.

The h1 through h6 element tags must be in a sequentially-descending order for headings to be in a correct logical order.

The fundamental goal of headers is to communicate the page’s organizational structure. The same goal is served by employing various font sizes for sighted users.

For screen reader users, however, text size is useless because a screen reader can only recognize a header if it is correctly marked up. When header components are used correctly, both sighted and screen reader users will find it much simpler to traverse the page.

Users of screen readers can navigate between headings in the same manner that sighted users might skim a page to gain a sense of its contents. Users, especially those who use screen readers, can save a ton of time and stress by using well-written, logically-arranged headings.

Headings serve to explain the organization of the webpage, not only to draw attention to key text. They ought to be succinct, distinct, and accompanied by h1 through h6 components used in hierarchical order. Headings are useful tools for screen reader users because of all of these characteristics. Screen reader users can move among headings in a manner akin to how sighted readers can quickly scan a page and get a sense of its content. Screen readers can save time and stress by using headings that are clearly written and arranged.

Since search engines employ headings when filtering, arranging, and showing results, headings offer other advantages outside just making the page more easily accessible. Making your website more searchable is another benefit of making it more accessible.

What this Accessibility Rule Checks

Ensures the semantic accuracy of the headings’ order.