Landmarks and ARIA regions: header, nav, main and footer

A landmark is a section of a page that has a role, and often a name, so that assistive technology can list it and jump to it. The roles come from ARIA (Accessible Rich Internet Applications), W3C's set of roles and attributes that tell assistive technology what an element is. The ARIA Authoring Practices Guide (APG) says screen readers use landmark roles to provide keyboard navigation to the important sections of a page, and that landmarks can also be targets for skip links and browser extensions (APG, landmark regions). HTML creates the common ones from elements you probably already use. The work is in the details: which elements count, when a landmark needs a name, and what to leave out.

Headings give the outline inside the main content; see our heading structure guide.

What landmarks do for the people who use them

W3C's technique ARIA11 says landmarks help assistive technology users orient themselves and move between sections of a page, and skip blocks that repeat on many pages, such as a site-wide menu. Its example is a blind visitor who knows a news site's menu and jumps straight to the main landmark.

In NVDA, a free screen reader for Windows, pressing D in browse mode (its reading mode for web pages) moves to the next landmark and Shift+D to the previous one, and the Elements List (NVDA+F7) can list landmarks (NVDA user guide). Other screen readers have their own commands; our guide to how a screen reader reads a page shows where landmark navigation fits.

Two consequences follow. ARIA11 notes that browsers do not expose landmarks directly to users, so a missing or misnamed landmark never shows in the visual design and has to be checked on purpose. It also says sighted keyboard-only users can reach landmarks through a browser plugin, so in our reading a skip link stays worth having beside them.

The landmark roles and the HTML that creates them

The APG lists eight landmark roles and the HTML element behind each. The condition column is where most mistakes start. An accessible name is the text by which software identifies an element to the user, such as the text of an aria-label attribute.

W3C's Page Regions tutorial says a header or footer inside an article or section gets no banner or contentinfo role. ARIA in HTML, the W3C Recommendation that maps elements to roles, gives the same rule and says a section without an accessible name is a generic container.

Prefer the element to the attribute. The tutorial says to add ARIA roles to div elements when HTML5 cannot be used or an older page is being retrofitted, and ARIA in HTML lists a main element with role="main" as a redundant role to avoid. The older pattern looks like this:

<div class="header" role="banner">...</div>
<div id="main" role="main">...</div>
<div id="footer" role="contentinfo">...</div>

For search, the APG uses the search element, or role="search" when that element is not used, in place of a form landmark. For roles and names more generally, see our ARIA basics guide.

A page skeleton that works

This skeleton uses each element once, in the places the APG describes. The names and text are placeholders.

<body>
  <a href="#main">Skip to content</a>
  <header>
    <a href="/">Example Co home</a>
    <nav aria-label="Main">...</nav>
  </header>
  <main id="main">
    <h1>Page title</h1>
    ...
  </main>
  <aside aria-labelledby="note-heading">
    <h2 id="note-heading">Side notes</h2>
    ...
  </aside>
  <footer>...</footer>
</body>

The nav sits inside the header, which is allowed because the APG says landmarks can be nested. Banner, main, complementary and contentinfo should be top level, so the aside sits beside main, not inside it. The skip link targets the id on main, as MDN's page on the main element shows. The skip link comes first, so it sits outside every landmark; in our reading that is a fair exception, because its job is to get past them.

GotAlt's own pages use the same core: a header with a nav labeled Main, a main element with the id main, and a footer. On a site builder, check the page's output, not the editor; our Webflow accessibility guide has a section on landmarks in the Designer.

When a landmark needs a name

A name tells a listener which landmark they are in. The APG's rule is that if a role appears more than once on a page, each instance needs a unique label. W3C's Labeling Regions tutorial adds that unique regions, such as main, need no extra label.

If the area begins with a heading, the APG says that heading can be the label, through aria-labelledby; if there is no heading, use aria-label. Both patterns appear in the tutorials:

<nav aria-label="Main">...</nav>

<nav aria-labelledby="toc-heading">
  <h2 id="toc-heading">On this page</h2>
  ...
</nav>

Leave the role out of the label. The APG's example is a navigation landmark labeled "Site Navigation", which a screen reader announces as "Site Navigation Navigation"; the label should be just "Site". Instances with identical content and purpose, such as the same pagination controls above and below a results table, may share a label.

Regions, sections and forms: when not to add a landmark

More landmarks are not better. Each one is an entry in the list a screen reader user scans, so add them where a listener would want to jump.

• Region. W3C's technique ARIA20 is for content that no standard landmark fits, such as a weekly poll on a news home page. ARIA20 says it is important to name regions, and to use them prudently because overuse can make a page verbose for screen reader users.
• Section. A section without a name has no landmark role, so using it for styling or outline adds nothing to the list. Name one and it becomes a region, so name only the few you want listed. WebAIM says labeling section and article is rarely useful.
• Navigation. The Page Regions tutorial says a page can have any number of navigation menus. WebAIM advises nav mainly for the primary navigation, not for every list of links or for the footer. In our reading, use nav for sets of links a listener may want to jump to or past, and name any you repeat. See accessible link text for the links inside.
• Form. ARIA in HTML notes that a form is not exposed as a landmark without an accessible name, and the APG says to use the search landmark for a search form. See accessible forms.
• Dialogs. The APG says wrapping a modal dialog's content in a landmark is unnecessary, because the dialog already provides a name and boundaries. See accessible modals.

Mistakes that break landmark navigation

• No main, or two of them. The APG says each page should have one main landmark. The HTML Standard says a document must not have more than one main element that lacks the hidden attribute, so an app that keeps one main per view must hide all but the current one.
• A main in the wrong place. The HTML Standard limits a main element's ancestors to html, body, div, a form without an accessible name and autonomous custom elements. A main inside an article or section breaks that rule.
• A site header or footer inside a sectioning element. Inside article, aside, main, nav or section, header and footer are not banner or contentinfo. If a template wraps the site header in a section, a listener finds no banner.
• Content outside every landmark. The APG says that including all perceivable content in landmarks is one of the most effective ways to ensure assistive technology users do not overlook it. Anything added before the header or after the footer, such as a notice bar, sits outside them unless you place it inside one. A skip link at the very top is the one exception we would make, because its job is to get past the landmarks.
• Unnamed duplicates and role words in labels. Two nav elements with no names are announced alike, and "Main navigation" says "navigation" twice.

Landmarks and WCAG

WCAG has no rule that says "use landmarks". W3C documents them as sufficient techniques for these two criteria (ARIA11 also lists 1.3.6 Identify Purpose). For 1.3.1 Info and Relationships (Level A), which asks that information and structure shown through presentation can be determined by software or are available in text, W3C's Understanding page lists ARIA11, ARIA13 (naming regions with aria-labelledby), ARIA20 (the region role) and H101, the technique for semantic HTML elements. For 2.4.1 Bypass Blocks (Level A), the Understanding page lists ARIA11 as sufficient when it groups repeated blocks so they can be skipped, alongside skip links (G1) and headings (H69).

W3C says every technique is an example of a way to meet WCAG, and that content can meet a criterion without it. So a page with no landmarks is not automatically a failure, and one with them is not automatically a pass. The Page Regions tutorial also lists 2.4.6 Headings and Labels (Level AA) as related. Our reading is to use the routes together: landmarks for screen reader users, a skip link for people who tab, and headings inside the main content. The WCAG 2.2 checklist covers the other criteria.

How to test landmarks

Landmarks do not show on the page, so testing needs a screen reader or a view of the accessibility tree. It takes a few minutes per template.

1. Jump through them. Load the page in NVDA or another screen reader and press D repeatedly. Each press should land on a landmark, in page order, ending with the last one on the page, usually the footer. Shift+D goes back.
2. Read the list. Open the Elements List with NVDA+F7 and choose the landmarks. Read it as an outline of the page: one main, each navigation told apart by name, and no name that repeats its role.
3. Look at the tree. The Accessibility tab in Chrome DevTools shows the accessibility tree and the computed properties of each node, and Firefox's Accessibility Inspector lists each item's role and name. Use them to see which elements are exposed as landmarks, and whether any content sits outside all of them.
4. Apply W3C's test. ARIA11's procedure has four checks: examine each element with a landmark role, confirm it suits the content, confirm a name where the role needs one, and confirm each repeated type has a unique, meaningful name.

Run it on each template, such as the home page, an article and a checkout, not on every page. For the wider routine, see how to test website accessibility.

Check it yourself

Landmarks are a manual check: none of the rule checks listed on what we check is about them, and neither are the tools below. They cover the structure that sits beside landmarks:

• Heading checker draws the heading outline of a page from its address or pasted HTML, and flags a missing H1, more than one H1, skipped levels and empty headings. That is the outline inside your main landmark.
• Accessibility bookmarklet checks the page open in your browser, including pages behind a login, for alt text, heading outline, link and button names, form labels, language, title and text contrast. It does not report landmarks.
• WCAG audit checklist lets you track all 55 Level A and AA criteria, including 1.3.1 and 2.4.1, and export a CSV file.
• Scan my site for free runs 16 rule-based checks on up to 3 pages, including page titles, link and button names, form labels and skipped heading levels.

A clean result from any of them says nothing about landmarks. The screen reader test above covers that.