HTML Landmarks

If an issue entry sent you here, you're in the right place. This article explains what HTML landmarks are, which rules the landmark validations check, and how to structure a page so every landmark does its job. No prior experience with assistive technology is needed.

What landmarks are

Named regions of a page

HTML landmarks are named, high-level regions of a page like the header, navigation, main content, and footer. Browsers expose them to assistive technology through the accessibility tree, a structured version of the page built from your code. Landmarks make the visual structure of your layout available programmatically.

How assistive technology uses them

Screen readers let people list all landmarks on a page and jump straight to the one they want — for example, "go to main" or "open the landmarks list." In short: landmarks turn your visual layout into navigable waypoints for screen reader users.

Why landmarks matter

Fast navigation

Screen readers provide quick ways to list and jump between landmarks. On pages with repeated menus and sidebars, this can cut dozens of keystrokes.

Discoverability of structure

Landmarks are read out with their role and, if present, their accessible name — for example, "Navigation, Primary." This reinforces the information hierarchy for non-visual users.

Support for WCAG intent

Landmarks themselves aren't a strict WCAG requirement, but they support success criteria 1.3.1 Info and Relationships and 2.4.1 Bypass Blocks by conveying structure and letting users skip over repeated content blocks.

Landmark types

Structural landmarks

Structural landmarks define the high-level regions of the page:

• banner — the site-wide header. A top-level <header> (direct child of <body>) maps to banner. A <header> nested inside article, section, main, aside, or nav does not. Keep one banner per page
• main — the primary content of the page. Use <main>. Keep one top-level main per page (each embedded document, like an <iframe>, can have its own)
• contentinfo — the site-wide footer. A top-level <footer> maps to contentinfo; a <footer> nested in article, section, main, aside, or nav does not. Keep one per page
• complementary — a supporting region related to, but separate from, the main content (think sidebar). Use <aside> at the top level. If you have more than one, give each a unique accessible name
• region — a named section important enough to navigate to that doesn't fit the other landmark types. A <section> becomes a region landmark only when it has an accessible name

Operational landmarks

Operational landmarks identify areas where users take action:

• navigation — groups of links used to move around the site or page. Use <nav>. If you have more than one (for example, primary versus footer links), give each a unique, concise accessible name
• search — the site or page search area. You can use the <search> element (supported in current Chrome, Edge, Firefox, and Safari) or a container with role="search", commonly a <form>
• form — a landmark for a significant, named form, like "Checkout" or "Newsletter sign-up." A <form> becomes a form landmark only when it has an accessible name (via aria-labelledby, aria-label, or title). Use role="form" sparingly — prefer search for search forms and rely on <form> semantics when possible

Rules the landmark validations check

Place all content inside landmarks

It's a good practice to place every piece of perceivable content on the page inside a landmark. Content that sits outside all landmarks is easy to miss: users who navigate by landmark can jump past it without knowing it exists. The region validation flags content that doesn't belong to any landmark.

Keep one main, banner, and contentinfo

A page reads best with exactly one main, at most one banner, and at most one contentinfo. Duplicates create identical entries in the landmarks list, so users can't tell which one holds the real content. Validations flag pages with more than one of each.

Keep top-level landmarks at the top level

banner, main, contentinfo, and complementary belong at the top level of the page — not nested inside another landmark. Nesting them confuses the page outline and can hide them from some assistive technology. For example, an <aside> placed inside <main> is flagged as a nested complementary landmark.

Name duplicate landmarks

When you repeat a landmark type, give each instance a unique, concise accessible name — "Primary," "Footer links," "On this page." Avoid including the role word in the name ("Site navigation navigation" gets announced twice). Using a visible heading with aria-labelledby keeps the name in sync with what sighted users read.

Name every region

A <section> or role="region" without an accessible name is not exposed as a landmark at all. Tie the name to a visible heading with aria-labelledby where possible.

Semantic HTML vs. ARIA landmarks

Prefer native HTML

Many landmarks come "for free" from semantic elements: <main> maps to main, <nav> to navigation, a top-level <header> to banner, a top-level <footer> to contentinfo, <aside> to complementary, a named <section> to region, a named <form> to form, and <search> to search. This mapping appears in the accessibility tree and is recognized by screen readers.

Use ARIA when needed

Add explicit roles only when there isn't an appropriate native element, or when retrofitting older markup — for example, role="navigation" on a <div>. Following the "use HTML first" guidance helps you avoid conflicts and duplicate semantics.

Examples

1) A solid, labeled layout

This layout keeps every landmark at the top level, names the duplicates, and places all content inside a landmark.

<header>
  <a class="site-name" href="/">SpaceBear</a>
  <nav aria-label="Primary">…</nav>
</header>


<main id="content">
  <h1>Stellar launch weekend for SpaceBear 7</h1>


  <section aria-labelledby="updates-heading">
    <h2 id="updates-heading">Latest updates</h2>
    …
  </section>
</main>


<aside aria-label="Related articles">…</aside>


<search aria-label="Site">
  <form action="/search">
    <label for="q">Search SpaceBear</label>
    <input id="q" name="q" type="search">
  </form>
</search>


<footer>© SpaceBear · Accessibility · Privacy</footer>

• The top-level <header> and <footer> create banner and contentinfo
• The <aside> sits at the top level, next to <main> — not inside it — so it's exposed as a top-level complementary landmark
• The <section> becomes a region because aria-labelledby names it
• <search> maps to the search landmark in modern browsers; if you need wider fallback, wrap your form in a <div role="search">

2) When header and footer are not landmarks

A <header> or <footer> nested inside sectioning content is just a section header or footer — not a landmark.

<article>
  <header>Article meta & byline</header>   <!-- NOT a banner -->
  …
  <footer>Article footnotes</footer>       <!-- NOT contentinfo -->
</article>

These are not banner or contentinfo because they're not top-level.

3) Multiple navigations with names

Each navigation landmark gets a unique, meaningful name so screen readers can tell them apart.

<nav aria-label="Primary">…</nav>
<nav aria-labelledby="on-this-page-h2">
  <h2 id="on-this-page-h2">On this page</h2>
  …
</nav>

4) A named form landmark

A named <form> is exposed as a form landmark. Prefer aria-labelledby so the visible heading becomes the landmark's accessible name.

<form aria-labelledby="newsletter-h2">
  <h2 id="newsletter-h2">Newsletter sign-up</h2>
  <!-- fields -->
</form>

Practical tips

Keep the count sensible

Landmarks are most useful when there are just enough to reflect the layout. Too many, and the landmarks list becomes noise. A common rule: one banner, one main, one contentinfo, and as many navigation, complementary, and region landmarks as the layout needs — with names on the duplicates.

Reserve region and form for significant areas

Avoid role="region" on every wrapper and role="form" on every small group of controls. Reserve them for sections and forms important enough that a user would want to jump directly to them.

Verify in the accessibility tree

In Chrome or Edge DevTools (Elements → Accessibility) or Firefox's Accessibility Inspector, select the elements you expect to be landmarks and confirm each one's role and accessible name. QA can include this in manual checks.

Test with a screen reader

Open the screen reader's landmarks list and check that the order and names make sense. In NVDA, D and Shift+D move across landmarks and NVDA+F7 opens the Elements List. In JAWS, R and Shift+R move across landmarks and Insert+Ctrl+R opens the Landmarks list. In VoiceOver, use the Rotor → Landmarks.

New to screen readers? Start with Practical guides for using screen readers, then follow the hands-on guide for VoiceOver on Mac or NVDA on Windows.

Note: A landmarks overlay, like the one in Accessibility Insights, can visualize regions directly on the page — a quick way to spot content that sits outside all landmarks.

Quick reference

Common pitfalls to avoid

• Multiple main landmarks in one document
• Content left outside all landmarks
• Unlabeled duplicate navigation or complementary landmarks
• Assuming nested <header> and <footer> are banner and contentinfo — they aren't
• Nesting <aside> or <main> inside another landmark
• Using role="region" everywhere instead of reserving it for important, named sections
• Adding role="form" to every small group of controls instead of significant, named forms