Axe Core Guide
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.
Learn more:
Related Accessibility Rules
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.
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.
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.
Notifies users of content that is hidden and unable to be checked for accessibility issues.
It is impossible to automatically check hidden content for accessibility rules breaches.
Screen reader users and sighted people must both be able to view visually hidden content. When content needs to be hidden from seeing users for a compelling reason, it is typically also necessary to hide it from blind users for the same reason. Making the content accessible to blind users makes sense when it is already available to sighted users.
When the CSS values display: none or visibility: hidden are used, content will be hidden from screen reader users (and all sighted users as well). The items become accessible to screen reader users when CSS properties are changed to display: block, display: inline, or other display values.
What this Accessibility Rule Checks
Checks for the presence of the hidden item content CSS style property values of display: none and visibility: hidden, and notifies users of their presence.
When button and link text in an alt property value repeats, screen reader users hear the same information twice, rendering the alt text worthless and confusing.
It is redundant and potentially misleading to have alternate text for a link or image repeated in text adjacent to the link or image because a screen reader would read it twice.
Because image buttons employ alt attributes for labels, the labels should not repeat the text next to the button. Screen readers announce the text to the user twice when there is duplicate alternative text for an image or link in the text adjacent to that image or link.
What this Accessibility Rule Checks
Make certain that the button and link text are not repeated as picture alternatives.
The user-scalable="no" parameter in the <meta name="viewport"> element must not be used since it prevents text scaling and zooming, which are necessary for individuals with impaired vision.
The option user-scalable="no" within the content attribute of the <meta name="viewport"> element prevents page zooming.
The maximum-scale setting restricts the user’s ability to zoom.
This is troublesome for individuals with low vision who rely on screen magnifiers to view web page content.
Users with partial or low vision frequently choose to increase their browser’s fonts to make web content easier to read. Everything visible in the browser window at a given time is the viewport focus. If the user maximizes the browser on a high-resolution display, the viewport’s focus area is expansive and may encompass the entire online page.
If the browser window is small, only a small portion of the web page is visible in the viewport focus region. The viewport focus of the browser has no effect on the programmatic focus. Users can scroll the web page up and down, but the focus does not follow the viewport. Developers are required by the Web Content Accessibility Guidelines to build pages to enable resizing up to 200%; nevertheless, it is considered best practice to demand a 5x zoom.
What this Accessibility Rule Checks
Ensures that the user-scalable="no" parameter is absent from the <meta name="viewport"> element, and that the maximum-scale parameter is greater than or equal to 500%