ARIA Landmarks & Page Structure
A sighted user sees a page’s structure at a glance: header on top, main column in the middle, sidebar to one side, footer at the bottom. A screen reader user gets that same structure only if you put it in the markup. This guide covers the two maps they navigate by, landmarks and headings, the eight landmark roles and the HTML that provides them, the scoping and naming rules almost everyone gets wrong, and how real screen readers jump around a page by structure. Copy-ready HTML mapped to WCAG 2.2.
Why Page Structure Is an Accessibility Feature
When you look at a web page, you take in its structure before you read a single word. Your eye separates the banner across the top, the main article in the center, the related links down the side, and the legal text in the footer, and you jump straight to whichever one you came for. That instant overview is a genuine feature of the page, and it is entirely visual. A screen reader user cannot glance. They receive the page as a linear stream, one element after another, and the only way they get the same overview is if the structure is written into the HTML so their software can expose it.
Two mechanisms carry that structure, and they are complementary. Landmarks are the small set of major regions, the banner, the navigation, the main content, the sidebar, the footer. Headings are the fine-grained outline inside those regions, from the page’s h1 down through its sections and subsections. A screen reader lets a user list all the landmarks on a page and jump between them, and separately list all the headings and jump between those. Together they reproduce, for a non-visual user, the scanning a sighted user does with their eyes.
The idea that ties this guide together
Landmarks and headings are two navigation maps that most developers never see, because they are exposed to assistive technology rather than drawn on the screen. When you use <header>, <nav>, <main>, <aside>, and <footer>, and a clean sequence of heading levels, you are not decorating; you are drawing both maps. Skip those elements and reach for <div> for everything, and the page has no map at all: a screen reader user has to read it top to bottom every time, with no way to skip the parts they have already heard.
This is not an edge case for a few users. Structure is the backbone of 1.3.1 Info and Relationships, one of the most-cited WCAG failures on the web, and it is what makes the bypass mechanisms in skip links and bypass blocks possible in the first place. Good structure also happens to be the cheapest accessibility win there is: it is mostly a matter of choosing the right element, and it helps everyone, including search engines that read your page’s outline the same way.
How Page Structure Maps to WCAG 2.2
The highlighted row, 1.3.1 Info and Relationships, is the heart of the matter: the structure a sighted user perceives visually must also be exposed in the markup. The other rows are the criteria a well-structured page satisfies along the way, from the bypass that landmarks enable to the accessible names that keep two regions of the same type apart.
| Criterion | Level | How it applies to page structure |
|---|---|---|
| 1.3.1 Info and Relationships | A | The regions and outline a sighted user sees must be exposed in code. Landmarks convey the major regions and headings convey the content hierarchy, so assistive technology can present the same structure. |
| 2.4.1 Bypass Blocks | A | Landmark regions are an accepted way to skip repeated content: a screen reader user jumps straight to the main landmark past the header and navigation. |
| 2.4.2 Page Titled | A | The document title is the top of the structure. A descriptive, unique title names the page in the tab, in history, and in the screen reader’s announcement when the page loads. |
| 1.3.2 Meaningful Sequence | A | The reading order that assistive technology and the keyboard follow is the DOM order, not the visual order. Source order must make sense even when CSS moves things around. |
| 2.4.6 Headings and Labels | AA | Headings and the accessible names of landmarks must describe the topic or purpose of the content they head, so the outline and the landmarks list are useful, not generic. |
| 4.1.2 Name, Role, Value | A | Each landmark exposes a role. When two landmarks share a role, such as two navigation regions, each needs a distinct accessible name so they can be told apart. |
| 2.4.10 Section Headings | AAA | Where content is organized into sections, headings are used to mark them. This is the fine-grained half of the structure, and it is an enhancement above AA. |
Each criterion links to its full reference and interactive demo. The complete WCAG 2.2 criteria are one click away.
1. The Eight Landmark Roles, and the HTML That Gives Them to You
There are eight landmark roles in ARIA, and for five of them there is a native HTML element that provides the role automatically. The single most important rule of this guide follows the first rule of ARIA: if a native element gives you the landmark, use the native element and do not add the role attribute on top. Writing <header role="banner"> is redundant, and a <div role="main"> is a worse version of <main>.
| Landmark role | Native HTML | What it is for |
|---|---|---|
| banner | <header> at the top level | Site-orientation content repeated across pages: the logo, site name, and often the primary navigation and search. |
| navigation | <nav> | A group of navigation links. A page can have several; name each one. |
| main | <main> | The primary content unique to this page. Exactly one per page. |
| complementary | <aside> | Supporting content that makes sense on its own: related links, a pull quote, an ad rail. |
| contentinfo | <footer> at the top level | Information about the page: copyright, legal links, contact, footer navigation. |
| search | <search>, or role="search" on a form | The search facility for the site or page. The native <search> element is newer; role="search" on the form is the widely supported technique. |
| form | <form> with an accessible name | A significant form region. A form becomes a landmark only when it has a name; use it for major forms, not every input group. |
| region | <section> with an accessible name | A major section important enough to be a landmark. Only counts when named, so use it sparingly. |
Put the common ones together and a well-structured page has a clean skeleton that reads as a map before you add any content:
<body>
<header> <!-- banner -->
<a class="skip-link" href="#main">Skip to main content</a>
<a href="/"><img src="/logo.svg" alt="Acme"></a>
<nav aria-label="Primary"> <!-- navigation -->
<ul> ... </ul>
</nav>
<search> <!-- search -->
<form role="search">
<label for="q">Search Acme</label>
<input id="q" type="search" name="q">
<button type="submit">Search</button>
</form>
</search>
</header>
<main id="main"> <!-- main: exactly one -->
<h1>Accessible page structure</h1>
<p> ... primary content ... </p>
<aside aria-label="Related guides"> <!-- complementary -->
<h2>Related guides</h2>
<ul> ... </ul>
</aside>
</main>
<footer> <!-- contentinfo -->
<nav aria-label="Footer"> <!-- navigation, named -->
<ul> ... </ul>
</nav>
<p>© 2026 Acme</p>
</footer>
</body>That is the target shape. The rest of this guide is about the rules that decide whether these elements actually become the landmarks you expect, because several of them do not behave the way their tag names suggest.
2. Landmark Scoping: the Rule Almost Everyone Misses
Here is the detail that trips up even experienced developers: <header> and <footer> only expose the banner and contentinfo landmark roles when they are at the top level of the document. Nested inside a <main>, <article>, <aside>, <nav>, or <section>, a <header> or <footer> exposes no landmark role at all; it is treated as an ordinary container. This is by design, and it is usually what you want.
Think about a page that lists twenty article cards, each with its own <header> holding the title and its own <footer> holding the byline. If every one of those became a landmark, the landmarks list would fill with twenty banners and twenty contentinfos, which is useless. Because banner and contentinfo are scoped to the top level only, you get exactly one of each, the page banner and the page footer, and the card headers and footers stay quiet. The scoping is protecting you.
Where scoping bites: the disappearing footer
The flip side is that if you accidentally move your page footer inside <main>, or wrap the whole page body in a single <section> or <article>, the top-level <header> and <footer> silently lose their banner and contentinfo roles, and those landmarks vanish from the map. Keep the page banner and the page footer as direct children of <body> (or of a simple layout wrapper that is not a sectioning element), so they stay at the top level.
Not every element is scoped this way. The table below shows which landmarks are always exposed and which depend on where they sit or whether they are named.
| Element | Becomes a landmark |
|---|---|
<main>, <nav> | Always, wherever they sit in the document. |
<header>, <footer> | Only at the top level. Nested inside main, article, aside, nav, or section they expose no landmark role. |
<aside> | At the top level, always complementary. Nested inside article or section it is complementary only if it has an accessible name; otherwise it is a generic container. |
<section> | Only when it has an accessible name, and then it is a region. Unnamed, it exposes no role. |
<form> | Only when it has an accessible name, and then it is a form landmark. Unnamed, it is not a landmark. |
<search> / role="search" | Always a search landmark. |
The practical takeaway: use <header> and <footer> freely inside cards and articles for clean markup, knowing they will not pollute the landmarks list, and be deliberate about keeping the page-level banner and contentinfo where the scoping rule can find them.
3. One Main, and Naming Repeated Landmarks
Two rules govern how many landmarks you have and how a user tells them apart.
Exactly one main
A page has one <main> landmark, and it holds the content unique to that page, everything that is not the repeated banner, navigation, sidebar, or footer. The main landmark is the destination the whole bypass model points at: when a screen reader user presses the shortcut to jump to main, there must be a single, unambiguous target. Two main elements break that, and some assistive technology flags it as an error or ignores the extra one. In a single-page app, keep one main and swap its contents as the route changes, rather than mounting a second main per view.
Name every repeated landmark
When a page has more than one landmark of the same type, each one needs a distinct accessible name, or the user cannot tell them apart. Two <nav>regions both announce as “navigation”, so a user browsing the landmarks list hears “navigation, navigation” with no way to choose. Give each a name with aria-label or aria-labelledby:
<nav aria-label="Primary"> <!-- announced: "Primary navigation" -->
<ul> ... </ul>
</nav>
<nav aria-label="Breadcrumb"> <!-- announced: "Breadcrumb navigation" -->
<ol> ... </ol>
</nav>
<nav aria-label="Footer"> <!-- announced: "Footer navigation" -->
<ul> ... </ul>
</nav>Two rules keep those names clean. First, do not put the role word in the name. The role already contributes “navigation”, so aria-label="Primary navigation"is read as “Primary navigation, navigation”; write Primary. Second, when there is a visible heading that already names the region, point at it with aria-labelledby instead of retyping the text, so the name stays in sync:
<aside aria-labelledby="related-heading">
<h2 id="related-heading">Related articles</h2>
<ul> ... </ul>
</aside>This naming is the 4.1.2 Name, Role, Value tie-in for structure: the role comes from the element, and you supply the name that distinguishes one instance from another.
4. The Section Trap: a Section Is Only a Landmark When You Name It
A common misconception is that wrapping content in <section> makes it a landmark. It does not. A <section> exposes the region landmark role only when it has an accessible name. An unnamed <section> is, to assistive technology, an ordinary generic container: it adds nothing to the landmarks list, and a screen reader will not announce entering or leaving it. So a page sprinkled with a dozen bare <section> tags has, from a landmark point of view, no extra structure at all.
To turn a section into a region landmark, name it, usually by pointing aria-labelledby at its heading:
<!-- Not a landmark: unnamed section, exposed as a generic container -->
<section>
<h2>Pricing</h2>
...
</section>
<!-- A region landmark: the section is named by its heading -->
<section aria-labelledby="pricing-heading">
<h2 id="pricing-heading">Pricing</h2>
...
</section>The requirement to name it is deliberate, and it points to the right way to use region. If every <section> became a landmark automatically, a long article split into ten sections would show ten regions in the landmarks list, drowning the useful landmarks (banner, main, footer) in noise. So the guidance is to be sparing: reserve named regions for a small number of genuinely major areas of the page that a user might reasonably want to jump to, such as a distinct “Filters” panel beside a product grid, or the main regions of a dashboard. For everything else, an ordinary heading already provides the structure, and it does so without adding to the landmark count.
A simple decision for section vs heading
Would a user want a landmark shortcut straight to this area, the way they jump to main or search? If yes, and there are only a few such areas, make it a named <section> (a region). If it is just the next part of the reading flow, use a heading and a plain <section> or <div>. When in doubt, prefer a heading: the heading map can be as detailed as you like, whereas the landmarks list works best when it stays short.
The same “named or nothing” rule applies to <form>: a form is a landmark only when it has an accessible name, so a labeled login or checkout form becomes a form landmark, while a small unnamed inline form does not clutter the list. The dedicated accessible forms guide covers labeling and grouping inside forms in depth.
5. The Heading Map: the Other Half of Page Structure
Landmarks give the few big regions; headings give the outline inside them, and screen reader users rely on headings even more heavily than on landmarks. In WebAIM’s surveys of screen reader users, navigating by heading is consistently one of the most-used ways to find information on a page. A user lists all the headings, reads the outline like a table of contents, and jumps to the one they want. That only works if your heading levels tell the truth about the structure.
The three heading rules
First, one <h1> per page, naming what the page is about. It is the root of the outline, and it usually matches the main subject in the <title>. Second, do not skip levels going down: an <h2> can be followed by an <h3>, but jumping from <h2> straight to <h4> leaves a gap in the outline that tells a screen reader user a level is missing. (You can jump back up any number of levels when a section ends; the no-skipping rule is about going deeper.) Third, heading level is about structure, not size: never pick a heading level because you want bigger or smaller text. Mark up the real level and use CSS for the appearance.
<h1>Accessible page structure</h1>
<h2>Landmarks</h2>
<h3>The eight roles</h3>
<h3>Scoping</h3>
<h2>Headings</h2>
<h3>The three rules</h3>
<!-- Wrong: the visual designer wanted a small heading, so h4 was used -->
<h2>Landmarks</h2>
<h4>The eight roles</h4> <!-- skipped h3: the outline now has a hole -->The HTML5 document outline is a myth
You may have read that with HTML5 you can use <h1> inside every <section> and <article>, and the browser will compute the real heading levels from the nesting. That was a proposed “document outline algorithm”, and it was never implemented by a single browser or screen reader. It has since been removed from the HTML specification, which now explicitly tells authors to use <h1> through <h6> to convey structure. In reality, a page of nested <h1> elements reads to a screen reader as a flat pile of top-level headings with no hierarchy. Always set heading levels explicitly.
Landmarks and headings answer different questions, and a good page answers both. Reach for a landmark when a user would want a shortcut to a whole region; reach for a heading to organize the content within a region. Where the two overlap, name the landmark from its heading with aria-labelledby so the region in the landmarks list and the entry in the headings list carry the same words. For a deeper look at how headings underpin the bypass model, see the skip links and bypass blocks guide.
6. Complete Coverage and Reading Order
Leave no content outside a landmark
A useful goal, and one the landmark checkers enforce, is that all of the page’s perceivable content sits inside some landmark. When a chunk of content falls between the landmarks, in a bare <div> that is a sibling of <main> rather than inside it, a user navigating by landmark can jump right over it and never know it is there. The fix is almost always to put that content where it belongs: inside <main> if it is primary content, inside the banner or footer if it is chrome, or into its own named region if it is genuinely a separate area. If a stray wrapper exists only for layout, it can stay a <div>, as long as its contents live inside a landmark.
Source order is the reading order
Structure is not only about which regions exist; it is also about the order they come in. Assistive technology and the keyboard follow the DOM order, the order elements appear in the HTML source, not the order CSS paints them on the screen. Flexbox order, grid placement, and absolute positioning can move a block visually without moving it in the DOM, and when they disagree, a screen reader user and a keyboard user experience the source order. This is 1.3.2 Meaningful Sequence: the sequence in which content is read must preserve its meaning. A classic failure is a “visually first” call to action that is placed last in the DOM, so keyboard users reach it only after everything else. Keep the DOM order sensible and use CSS for presentation, not to reorder content that a non-visual user needs in a particular sequence.
The page title sits above it all
The top of the structure is the document <title>. It is the first thing a screen reader announces when a page loads, it names the tab and the browser history entry, and it is what people see in a list of open tabs or search results. A descriptive, unique, front-loaded title, such as “Pricing, Acme” rather than “Acme” on every page, satisfies 2.4.2 Page Titled and is the difference between a user knowing which page they landed on and having to explore to find out.
7. How Screen Reader Users Navigate by Structure
All of this only matters because of what it lets users do. Every major screen reader offers single-key or rotor navigation by landmark and by heading, and this is where structure turns into speed. A user who knows the page has a main landmark and a clean heading outline does not read from the top; they jump. Knowing these commands also makes your own testing far faster.
| Screen reader | Move by landmark / region | Move by heading | List everything |
|---|---|---|---|
| NVDA (Windows) | D and Shift+D for the next and previous landmark. | H and Shift+H, or number keys 1 to 6 for a specific level. | Elements List, NVDA+F7, then choose Landmarks or Headings. |
| JAWS (Windows) | R and Shift+R cycle through regions, the JAWS term for landmarks. | H and Shift+H, or number keys 1 to 6. | Headings list with Insert+F6. |
| VoiceOver (macOS) | Open the rotor with VO+U and arrow to the Landmarks menu. | VO+Command+H, or the Headings menu in the rotor. | The rotor, VO+U, lists landmarks and headings in separate menus. |
On mobile, the pattern is the same through a gesture rather than a key: VoiceOver on iOS and TalkBack on Android both have a rotor or reading-control that includes Landmarks and Headings, so a user swipes to move between your regions and headings the same way. The lesson for you as a builder is that a clean structure is not a checkbox; it is a set of working shortcuts your users press dozens of times a day.
8. Testing Page Structure
See the map for yourself
The fastest first check is to visualize the landmarks and outline a page exposes. Browser extensions such as a dedicated landmarks viewer, the structure panel in WAVE, or the accessibility tree in your browser’s developer tools all draw the regions and the heading hierarchy for you. Open one and ask a simple question: does this match what a sighted user sees? There should be one banner, one main, one contentinfo, a named navigation for each distinct nav, and a heading outline with a single h1 and no gaps.
Confirm it with a screen reader
Then use the commands from the previous section. Open the landmarks list and confirm every region has a clear name and there are no surprises, no duplicate unnamed navs, no accidental extra banners from a nested header. Open the headings list and read it like a table of contents: it should make sense on its own and let you predict what is in each section. If the outline reads as a logical summary of the page, your structure is sound.
What tools catch, and what they do not
Automated checkers such as axe and WAVE are genuinely good at the mechanical structural rules: a missing or duplicated main, a page with no h1, skipped heading levels, content outside all landmarks, and two landmarks of the same type without distinct names. Run them and fix what they flag. What they cannot judge is whether the structure is right: whether your h1 actually describes the page, whether a landmark’s name is meaningful, whether the region you marked as main is really the main content, or whether the outline matches the visual design. As the automated versus manual testing guide explains, structure is a place where the machine gets you to a valid page and a human decides whether it is a good one. For where this fits in a full review, see the accessibility audit guide.
Common Page Structure Mistakes & How to Fix Them
These are the errors that turn up most in real structural audits. Most come back to two habits: reaching for <div> when a semantic element exists, and assuming an element becomes a landmark without checking the scoping and naming rules.
| Anti-pattern | Why it fails | The fix |
|---|---|---|
| The whole page is built from div elements with no landmarks. | A screen reader user gets no region map and no way to skip repeated content; the page is one undifferentiated stream (weakens 1.3.1 and 2.4.1). | Use the native sectioning elements: header, nav, main, aside, and footer, so the page exposes banner, navigation, main, complementary, and contentinfo for free. |
| The page has two main elements, or none. | The jump-to-main shortcut has no single destination, so the primary bypass target is ambiguous and some assistive technology reports an error (fails 1.3.1). | Use exactly one main element per page, holding the primary content, and keep swapping its contents on client-side route changes instead of mounting a second one. |
| Two nav or two aside regions with no accessible name. | Both announce identically, as navigation, navigation, so a screen reader user cannot tell the primary nav from the footer nav (fails 4.1.2). | Give each repeated landmark a unique accessible name with aria-label or aria-labelledby, and do not include the role word (navigation, region) in the name. |
| Section elements scattered everywhere in the hope they create landmarks. | An unnamed section exposes no role at all, so it does nothing for structure, while naming every section would flood the landmarks list with noise. | Name only the few sections that are genuinely major page regions with aria-labelledby, and use ordinary headings to organize everything else. |
| Heading levels are skipped, or headings are chosen for their font size. | Jumping from h2 to h4 breaks the outline a screen reader builds, and marking text as a heading only to make it big misrepresents the structure (weakens 1.3.1 and 2.4.10). | Use one h1 and then sequential levels that reflect the real hierarchy, and control visual size with CSS, never by picking a different heading level. |
| A top-level footer is nested inside main or an article, expecting it to stay contentinfo. | banner and contentinfo only apply at the top level; nested inside a sectioning element, header and footer expose no landmark role, so the region silently disappears from the map. | Keep the page banner and contentinfo as direct top-level regions, and treat header and footer inside cards or articles as ordinary content. |
| An aria-label duplicates the role word, like aria-label="Main content region". | The role is already announced, so the user hears the word twice: Main content region, region, which is verbose and confusing. | Name the purpose only. Let the role speak for itself and write labels like Primary, Footer, or Related articles. |
The Page Structure Checklist
- Native elements carry the regions. The page uses
<header>,<nav>,<main>,<aside>, and<footer>rather than<div>with landmark roles bolted on. - Exactly one main. There is a single
<main>holding the page’s unique content, and client-side routing swaps its contents rather than mounting a second one. - Banner and contentinfo are top level. The page
<header>and<footer>are direct top-level regions, not nested inside main or a section where they lose their role. - Repeated landmarks are named. Every duplicate landmark type, such as two navs, has a distinct
aria-labeloraria-labelledby, without the role word in the name. - Sections are landmarks only when intended. Named
<section>regions are reserved for a few major areas; the rest of the content is organized with headings. - One h1, no skipped levels. There is a single
<h1>, heading levels never jump a level going deeper, and level is chosen for structure, not font size. - No content outside a landmark. Every perceivable block sits inside a landmark, so nothing is skipped by a user navigating region to region.
- Source order matches reading order. The DOM order makes sense on its own, and CSS is used for appearance, not to reorder content non-visual users depend on.
- The title names the page. Each page has a unique, descriptive, front-loaded
<title>. - Verified with a screen reader. The landmarks list and the headings list have been opened in a real screen reader and match what a sighted user sees.
Structure First, Then the Bypass
Landmarks are the bypass for screen reader users; a visible skip link is the bypass for sighted keyboard users. Build both on top of a clean structure, and see exactly how structure satisfies Info and Relationships.
Frequently Asked Questions
What are ARIA landmarks?▾
Landmarks are the named regions of a page that a screen reader can list and jump between, the way a sighted user glances at the header, the main column, the sidebar, and the footer. There are eight landmark roles: banner, navigation, main, complementary, contentinfo, search, form, and region. You almost never write these roles by hand, because the HTML5 sectioning elements provide them for free: header maps to banner, nav to navigation, main to main, aside to complementary, and footer to contentinfo. Landmarks matter because they give a non-visual user the same overview and the same shortcuts a sighted user gets from layout. Without them, a screen reader user faces one undifferentiated stream of content with no way to skip to the part they want.
What is the difference between a landmark and a heading?▾
They are two separate navigation maps, and an accessible page provides both. Landmarks are the handful of big regions: this is the banner, this is the main content, this is the sidebar. Headings are the fine-grained outline inside those regions: the page title, then its sections and subsections. A screen reader user moves between landmarks to reach the right area, then moves between headings to find the right spot within it. Landmarks answer where am I on the page, and headings answer what is the structure of this content. Providing landmarks but no headings leaves users lost inside a region; providing headings but no landmarks makes them wade through the header and nav every time.
Do I need role="banner" if I already use a header element?▾
No. A top-level header element already exposes the banner role automatically, so adding role="banner" is redundant. The same is true for the other native elements: nav is already navigation, main is already main, aside is already complementary, and footer is already contentinfo. The first rule of ARIA applies here: if a native HTML element gives you the role, use it and do not add the ARIA role on top. You only reach for an explicit role attribute when you cannot use the native element, for example role="search" on a form, or a role on a div in a codebase that cannot change its markup.
Why is my section element not showing up as a landmark?▾
Because a section only becomes a region landmark when it has an accessible name. An unnamed section exposes no role to assistive technology at all; it is treated as a generic container, invisible in the landmarks list. To turn a section into a landmark, give it a name with aria-labelledby pointing at its heading, or with aria-label. This is deliberate: if every section were automatically a landmark, a content-heavy page would flood the landmarks list with dozens of unlabeled regions. Name the few sections that are genuinely major regions of the page, and let ordinary headings organize the rest.
How many main elements can a page have?▾
One. A page has exactly one main landmark, and it holds the primary content unique to that page, everything that is not the repeated header, navigation, sidebar, or footer. More than one main makes the region ambiguous, so a screen reader user pressing the shortcut to jump to main no longer has a single destination; some assistive technology ignores the extras or reports an error. If you are using a client-side router and swap the page content, keep swapping the contents of the same single main element rather than mounting a second one.
Is the HTML5 document outline real? Can I use h1 for every section?▾
No, and you should not. The HTML5 specification once described a document outline algorithm in which each sectioning element such as section or article would restart the heading scope, so you could use an h1 in every section and the browser would compute the real levels from the nesting. No browser and no screen reader ever implemented it, and it was removed from the specification. In practice, heading level comes only from the actual tag you use, so a page of nested h1 elements reads to a screen reader as many top-level headings with no hierarchy. Use explicit h1 through h6 levels that reflect the real structure, one h1 per page, and do not skip levels.
How do I label two navigation landmarks so they are not confused?▾
Give each one a distinct accessible name with aria-label or aria-labelledby. Two nav elements both announce as navigation, so a screen reader user hears navigation, navigation with no way to tell them apart. Label the main site navigation aria-label="Primary" and the one in the footer aria-label="Footer", and they become Primary navigation and Footer navigation. Do not put the word navigation in the label itself, because the role already contributes it: aria-label="Primary navigation" is announced as Primary navigation, navigation. The same rule applies to any repeated landmark type, such as two complementary regions or two named sections.
Do landmarks replace skip links?▾
Not entirely, because they serve different audiences. Landmarks are the bypass mechanism for screen reader users, who can jump straight to the main landmark and skip the repeated header. But a sighted keyboard user who does not run a screen reader has no landmark shortcut, so they still need a visible skip link to bypass the navigation. The accessible answer is to provide both: proper landmarks for screen reader users and a skip link for keyboard users, along with a clean heading structure that serves everyone. They reinforce each other rather than competing, which is why WCAG 2.4.1 accepts any of them as a valid bypass.
Essential Accessibility Resources
Comprehensive tools, checklists, and guides to help you create inclusive digital experiences