A sighted visitor scans a page visually and jumps straight to the content they want — skipping past the header, ignoring the sidebar, landing on the main article. A screen reader user, navigating linearly through the page’s structure, doesn’t get that shortcut unless the page explicitly provides one. ARIA landmark roles are that shortcut: a small, standardized vocabulary of region types that assistive technology surfaces as a navigable list, letting a screen reader user jump directly to the page’s main content, its navigation, or its footer without tabbing through everything in between.
The Landmark Roles
The ARIA landmark roles define a fixed set of region types:
banner— the site-wide header, typically containing the logo and top-level brandingnavigation— a collection of links for navigating the site or pagemain— the primary content of the page, unique per pagecomplementary— content that supports the main content but is meaningfully separate from it (a sidebar, a related-links panel)contentinfo— the site-wide footer, typically containing copyright, legal links, and contact informationsearch— a search form or search-related regionform— a region containing a form, when it should be independently navigable (typically only for significant forms, not every small input group)region— a generic labeled section that doesn’t fit any of the above, but is still significant enough to warrant being independently navigable (requires an accessible name to be meaningful as a landmark)
Assistive technology surfaces these as a jump-to list — in most screen readers, a dedicated keyboard shortcut opens a menu of every landmark on the page by its role and, where provided, its accessible name, letting the user navigate directly to any of them.
HTML5 Elements Already Carry Implicit Landmark Roles
The most important thing to know about landmark roles: for the most common cases, you don’t need to add an explicit role attribute at all, because the semantic sectioning elements introduced by the same HTML5 specification effort that gave the platform native video and audio elements already carry the equivalent implicit ARIA role:
| HTML5 element | Implicit landmark role |
|---|---|
<header> (top-level, not nested in <article>/<section>) | banner |
<nav> | navigation |
<main> | main |
<aside> | complementary |
<footer> (top-level) | contentinfo |
<form> with an accessible name | form |
<header><!-- implicit role="banner" --></header>
<nav><!-- implicit role="navigation" --></nav>
<main><!-- implicit role="main" --></main>
<aside><!-- implicit role="complementary" --></aside>
<footer><!-- implicit role="contentinfo" --></footer>
This means the single highest-leverage accessibility fix on many pages is simply using the correct semantic HTML5 element instead of a generic <div> — no role attribute, no ARIA at all, required to get the landmark benefit. Explicit role="navigation" on a <div> is only necessary when, for whatever reason, the semantic element itself isn’t being used.
Only One main, But Multiple of Everything Else
There is exactly one correct number of main landmarks per page: one. A page with zero <main> elements gives assistive technology no way to identify the primary content region at all; a page with more than one creates ambiguity about which one actually holds the page’s primary content. navigation, complementary, and region landmarks, by contrast, can appropriately appear multiple times on a single page — a page commonly has both a primary site navigation and a secondary “in this section” navigation, for example.
Labeling Multiple Landmarks of the Same Type
When a page has more than one landmark of the same role — two nav elements, for instance — each one needs a distinct accessible name, or a screen reader user navigating the landmark list will hear “navigation, navigation” with no way to tell them apart. aria-label provides that name directly:
<nav aria-label="Primary">
<!-- main site navigation -->
</nav>
<nav aria-label="Breadcrumb">
<!-- breadcrumb trail -->
</nav>
aria-labelledby, referencing the id of a visible heading, works the same way when there’s already a visible label element on the page that can serve as the accessible name, avoiding a duplicate string that has to be kept in sync with visible text:
<aside aria-labelledby="related-heading">
<h2 id="related-heading">Related Articles</h2>
<!-- ... -->
</aside>
Landmarks Are Not a Substitute for Heading Structure
Landmark navigation and heading navigation are two distinct systems that serve overlapping but different purposes, and screen reader users commonly rely on both. Landmarks describe a page’s broad structural regions — a handful per page, typically. Headings describe a document’s content outline — potentially dozens per page, at multiple nesting levels. A page with well-labeled landmarks but a broken or missing heading hierarchy is still difficult to navigate within its main region, since a screen reader user relying on heading-jump navigation has nothing correctly structured to jump between once they arrive there. The two systems should be treated as complementary requirements, not alternatives to each other.
A Common Mistake: Landmark Overuse
Wrapping every visually distinct section of a page in role="region" (or a generic labeled <section>, which carries the same implicit region role once it has an accessible name) produces the opposite of the intended benefit: a landmark list cluttered with a dozen or more entries defeats the purpose of a landmark list, which is to offer a small number of high-value jump targets. region is meant for content significant enough to warrant independent navigation — a page’s main sections, not every visual subdivision a page happens to have. As a practical guideline, if a landmark list wouldn’t fit comfortably in a short glance, it likely has too many entries.
Landmarks Inside Nested Contexts
A subtlety worth knowing: <header> and <footer> only carry their implicit banner and contentinfo landmark roles when they are direct children of the <body> — not when nested inside an <article>, <section>, <aside>, <main>, or <nav>. A <header> nested inside an <article> is treated as that article’s own internal heading area (its byline, publication date, and similar per-article metadata), not as the page’s overall site banner:
<body>
<header><!-- role="banner": this is the site header --></header>
<main>
<article>
<header><!-- NOT role="banner": this is just the article's own header --></header>
</article>
</main>
<footer><!-- role="contentinfo": this is the site footer --></footer>
</body>
This distinction matters because it’s easy to assume every <header> or <footer> on a page automatically becomes a landmark, and build a mental model of “one banner per page” that breaks down the moment an article-level header is added. The rule to remember: landmark-conferring status for header/footer depends on position in the document tree, not merely on the element name.
Verifying Landmark Structure
Landmarks are straightforward to verify without specialized screen reader expertise: most browser devtools accessibility panels display a page’s full accessibility tree, including every landmark region and its computed accessible name, and dedicated browser extensions exist specifically to list a page’s landmarks. Confirming the presence of exactly one main, appropriately labeled navigation regions, and a contentinfo footer is a fast check worth running on any page template, not just a final audit step reserved for launch. Because landmark support varies slightly across browser and screen-reader combinations, this check belongs in the same systematic pass as any other cross-browser compatibility testing — spot-checking one browser and assuming the result holds everywhere is exactly the assumption that workflow warns against.
Frequently Asked Questions
Do I need to add role attributes if I’m already using semantic HTML5 elements?
No, in most cases. <header>, <nav>, <main>, <aside>, and <footer> already carry their corresponding implicit ARIA landmark roles. Adding an explicit role attribute on top of the correct semantic element is redundant. Explicit roles are needed only when a landmark region can’t use the matching semantic element for some structural reason.
How many main landmarks should a page have?
Exactly one. A main landmark identifies the primary content region of the page, and having zero or more than one removes the clarity that landmark is meant to provide. Other landmark types, including navigation and complementary, can appropriately appear more than once per page.
What happens if I have two nav elements with no labels?
A screen reader user navigating the landmark list will hear both announced simply as “navigation,” with no way to distinguish which is the primary site navigation and which is something else, like a breadcrumb trail. Adding a distinct aria-label or aria-labelledby to each resolves the ambiguity.
Are landmarks a replacement for a proper heading structure?
No. Landmarks and headings serve different, complementary navigation needs — landmarks mark a page’s broad structural regions, while headings describe the content outline within those regions. A page needs both a correct landmark structure and a correct heading hierarchy to be genuinely easy to navigate for assistive technology users.
Can I use too many landmarks on one page?
Yes. Wrapping every minor visual section in a labeled region or section produces a cluttered landmark list that undermines the entire feature’s purpose — offering a small number of meaningful jump targets. Reserve region for content significant enough to justify independent navigation, not every visually distinct block on the page.