Axe Core Guide
Document should not have more than one main landmark
The core content of the page should only have one main landmark, and if the page contains iframe components, each one should either have no landmarks or just one. This is considered best practice.
If all of the content is divided up into one or more high-level divisions, screen reader users will have much easier time navigating a website. Outside of these categories, information can be hard to access and has an uncertain purpose.
Some essential semantic markers, such the ability to designate portions of the page as the header, navigation, primary content, and footer, have historically been absent from HTML. Although it’s recommended to combine HTML5 elements with ARIA markers in a single element, HTML regions will eventually prevail as browser support grows.
What this Accessibility Rule Checks
Makes sure there is just one primary landmark in the document.
Learn more:
Related Accessibility Rules
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.
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.
Best practice dictates that the primary landmark should not be enclosed within another landmark. All content must be contained within discrete areas, such as the header (role="banner"), body (role="main"), and footer (role="contentinfo").
Screen reader users can navigate a website much more easily if the content is divided into several high-level categories. It is difficult to locate content outside of these categories, and its purpose may be obscure.
Historically, HTML lacked essential semantic markers, such as the ability to define page sections as the header, navigation, primary content, and footer. Using both HTML5 elements and ARIA landmarks in the same element is considered an excellent practice, but as browser compatibility improves, HTML regions will likely become more popular in the future.
HTML Living Standard says “A hierarchically correct main element is one whose ancestor elements are limited to <html>, <body>, <div>, <form> without an accessible name, and autonomous custom elements. Each main element must be a hierarchically correct main element”. This may be a “recommended practice” according to W3C validation.
What this Accessibility Rule Checks
Ensures that all page content falls within a landmark region.
A best practice is to guarantee that there is only one primary landmark for navigating to the page’s principal content, and if the page has iframe components, each should contain either no landmarks or a single landmark.
If a website’s material is divided into one or more high-level parts, screen reader users will find it much easier to navigate. It is difficult to locate content outside of these categories, and its purpose may be obscure.
Historically, HTML lacked essential semantic markers, such as the ability to define page sections as the header, navigation, primary content, and footer. Using both HTML5 elements and ARIA landmarks in the same element is a best practice, but as browser support grows, the future will favor HTML areas.
What this Accessibility Rule Checks
Ensures that all page content falls within a landmark region.
The recommended practice is to keep all content, excluding skip links, in designated areas such the header, nav, main, and footer.
If the content is divided into several high-level divisions, screen reader users can navigate a website much more easily. Finding content that isn’t in parts can be challenging, and the item’s intent sometimes isn’t evident.
Some essential semantic markers, such as the ability to designate portions of the page as the header, navigation, primary content, and footer, were formerly absent from HTML. It is recommended to combine HTML5 elements with ARIA landmarks in a single element, but as browser support for HTML5 grows, using native HTML5 element regions will become more common.
What Checks This Accessibility Rule?
Ensures that a landmark region contains all of the content on a page.
For screen reader users to efficiently navigate tables, the scope element must be utilized correctly on tables in accordance with either HTML4 or HTML5 specifications.
If utilized properly, the scope feature greatly simplifies table navigation for screen reader users. When misused, scope can make table navigation far more difficult and ineffective.
The assumption made by a screen reader is that a table has a header that identifies a scope. Having an accurate header makes viewing a table for those who use screen readers far more accessible and effective due to the way the devices work.
What this Accessibility Rule Checks
Ensures that tables are correctly using the scope attribute.
In order to save viewers time, the website must contain a link at the top before the navigation that directs them directly to the page’s core content.
As it appears in the HTML file, screen readers read the text sequentially.
This has the effect of reading out to users of assistive technology the content at the top of the page, which normally includes the full navigation, before they can access any of the primary content. When a user is primarily interested in the main material, it might be time-consuming to listen to or navigate through all of the text at the top of the page because it is frequently very long.
Users who are blind, have low eyesight, or only use the mouse will benefit from an HTML website having a skip link.
What this Accessibility Rule Checks
Ensures that programmers adhere to the best practice of placing a skip link as the page’s very first link.
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.
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.