Home
Accessibility Guides
Current guide

Accessibility Axe Core 4.8

Document should not have more than one main landmark

Deque Best Practice
blind
deafblind
mobility
moderate

About This Accessibility Rule

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:

→ Deque University - How To Fix
→ WCAG 2.1 - Using ARIA landmarks to identify regions of a page

Was this guide helpful?

Detect accessibility issues automatically

Rocket Validator scans thousands of pages with Axe Core and the W3C Validator, finding accessibility issues across your entire site.

Start Free Trial See Pricing

Ready to validate your site?

Find Accessibility and HTML issues in your large sites, in seconds. Get your site scanned by Axe Core and W3C Validator with just one click.

Pro Trial Free Trial

Reading time

1 min read

Category

Accessibility Validation

Engine

Axe Core 4.8

Impact

moderate

Guidelines

Deque Best Practice

Disabilities

blind deafblind mobility

Resources

Deque University - How To Fix
WCAG 2.1 - Using ARIA landmarks to identify regions of a page

Related Accessibility Rules (97)

Heading levels should only increase by one

Deque Best Practice
blind
deafblind
mobility
moderate

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.

Aside should not be contained in another landmark

Deque Best Practice
sighted keyboard users
blind
deafblind
mobility
moderate

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.

Main landmark should not be contained in another landmark

Deque Best Practice
blind
deafblind
mobility
moderate

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.

Document should have one main landmark

Deque Best Practice
blind
deafblind
mobility
moderate

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.

All page content should be contained by landmarks

Deque Best Practice
blind
deafblind
mobility
moderate

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.

scope attribute should be used correctly

Deque Best Practice
blind
deafblind
mobility
moderate

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.

The skip-link target should exist and be focusable

Deque Best Practice
blind
deafblind
mobility
moderate

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.

ARIA role should be appropriate for the element

Deque Best Practice
blind
deafblind
mobility
minor

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.

Headings should not be empty

Deque Best Practice
blind
deafblind
mobility
minor

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.

What this Accessibility Rule Checks

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

Elements in the focus order should have an appropriate role

Deque Best Practice
blind
deafblind
mobility
minor

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.

Ready to validate your sites?
Start your free trial today.

Pro Trial Free Trial