Axe Core Guide
Ensure elements marked as presentational are consistently ignored
Checks to make sure elements selected for removal from the accessibility tree are really deleted.
In some circumstances, an element having a semantic role of none or presentation does not resolve to none or presentation (respectively).
This prevents the element from being eliminated from the accessibility tree, as would be expected, and allows screen readers to interact with it.
You shouldn’t focus the element or give it any global ARIA attributes in order to keep the element out of the accessibility tree.
What this Accessibility Rule Checks
Checks every element with role=“none” or role=“presentation” to ensure they do not have a global ARIA attribute and are not focusable.
Learn more:
Related Accessibility Rules
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.
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.
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.
Values assigned to ARIA role values must not be deprecated.
Using deprecated WAI-ARIA roles is bad for accessibility. They will not be recognized or correctly processed by screen readers and other assistive technologies. Using these means not everyone will be able to access essential information.
Ensure all values assigned to role="" correspond to WAI-ARIA roles that are not deprecated, or abstract. The following list indicates for each deprecated role a potential alternative that is better supported by assistive technologies:
-
directory: Consider using
section,list, ortreeinstead. Which is most appropriate depends on how directory was used.
What this Accessibility Rule Checks
Check all elements containing WAI-ARIA role attribute to ensure that the role is not deprecated in the latest version of the WAI-ARIA specification.
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.