Axe Core Guide

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.

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.

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.

Ensures the complementary landmark or aside is at top level.

Complementary content is content that supports the primary idea of a page or document. Users of screen readers have the option to bypass supplemental content that shows at the accessibility API’s top level. Embedding an <aside> element within another landmark may prevent the ability for screen reader users to browse through supplemental content.

What this Accessibility Rule Checks

Do not insert <aside> elements or elements containing role="complementary" inside landmark-marked content.

The contentinfo landmark must be at top level.

Placement of the contentinfo landmark within another landmark can contradict its purpose by preventing blind screen reader users from rapidly locating and navigating to the intended landmark.

It defeats the purpose of an existing contentinfo landmark when screen reader users must wade through too much extra information to discover what they seek, such as not being able to quickly determine which landmark provides the content information they seek.

What this Accessibility Rule Checks

This rule locates the components corresponding to the footer:not([role]) and [role="contentinfo"] selectors, and then tests whether the landmark has a body context.

Ensures there is only one banner landmark at most on the page.

Landmarks enable blind people to navigate and rapidly locate content. In the absence of landmarks, screen reader users must wade through too much unnecessary information to locate anything.

JAWS, NVDA, and VoiceOver all support using ARIA landmarks to navigate to specific portions of a web page. Landmarks offer a more elegant answer to the challenge of offering a way for readers to bypass the page’s main content. There is no visible change to the website’s layout, making it inconspicuous and undetectable. Obviously, the fact that this technique is invisible is advantageous for users of screen readers, but not for sighted keyboard users or users of screen magnifiers with impaired eyesight. In this sense, HTML 5 regions and ARIA landmarks cannot replace the conventional “skip navigation” links just yet.

There is presently no method built into browsers to alert users when HTML 5 regions or ARIA landmarks are available. Users of screen readers are the only ones who can benefit from them. There is a Firefox ARIA landmark extension that provides landmark navigation to Firefox, however this is not a native browser capability.

What this Accessibility Rule Checks

This rule locates all banner landmarks, filters out those that do not correspond to their job, and checks that there is only one.

Makes sure there is only one contentinfo landmark on the page.

You should keep the overall number of landmarks reasonably limited because one of their key functions is to help blind users locate and navigate to the proper landmark fast. Screen reader users will have to sift through too much unnecessary information if you don’t in order to find what they need.

Despite all the discussion about utilizing proper semantic structure for accessibility, HTML historically lacked some essential semantic markers, such as the ability to designate areas of the page as the header, navigation, main content, and footer. These designations are now feasible with HTML5 thanks to the new elements header, nav, main, and footer. The ARIA (Accessible Rich Internet Application) properties role="banner", role="navigation", role="main", and role="contentinfo" all provide similar capabilities.

ARIA landmarks can be used to navigate to specific web page areas in JAWS, NVDA, and VoiceOver. The issue of giving consumers an option to skip to the website’s primary material is addressed more tastefully by landmarks. The web design has not changed noticeably, making it invisible and undetectable. The fact that this method is invisible is obviously good for blind screen reader users, but it’s not so great for sighted keyboard users or people with impaired vision who use screen enlargers. In this sense, the traditional “skip navigation” links cannot yet be replaced with HTML 5 regions and ARIA landmarks.

Users are still unable to receive notifications from browsers that HTML 5 regions or ARIA landmarks are present. Only those who use screen readers can benefit from them. It is not a built-in capability of the browser, but there is a Firefox ARIA landmark extension that provides the ability to navigate by landmarks in Firefox.

What this Accessibility Rule Checks

This rule locates every contentinfo landmark, eliminates any that do not map their role, and confirms that there is only one.