Learn how to implement ARIA landmarks (main, nav, header, footer, aside) to improve web accessibility. Practical guide with code examples, skip links, and logical tab order for NVDA, JAWS, and VoiceOver screen readers.
What Are ARIA Landmarks and Why Should You Care?
Imagine walking into a library where every shelf looks the same, there are no signs, no sections, and no way to tell fiction from non-fiction. You would wander aimlessly, growing more frustrated with every step. That is exactly what happens when a screen reader user visits a website without ARIA landmarks. There are no signposts, no structure, just an endless stream of content with no way to jump to what matters.
ARIA landmarks are semantic regions defined by the WAI-ARIA specification from the W3C. They divide your web page into meaningful blocks: main navigation, primary content, the site banner, footer information, and complementary sidebars. Think of them as the chapter headings and table of contents that make a book navigable.
Personally, I believe landmarks are one of the highest-impact, lowest-effort accessibility improvements you can make. You do not need to redesign anything. You do not change the visual appearance of your site. You simply add semantic structure that makes life dramatically easier for people who rely on screen readers like NVDA, JAWS, or VoiceOver.
The Five Essential Landmarks Every Website Needs
The WAI-ARIA specification defines several landmark roles, but five of them form the backbone of any well-structured website. Let us look at each one in detail.
1. main: The Heart of Your Content
The main landmark identifies the primary content of your page. There should be exactly one per page, and it is where the screen reader expects to find the content that truly matters. If you use the HTML5 <main> element, the browser automatically assigns role="main". There is no need to duplicate it.
Have you ever searched for something on a website and had to wade through the menu, logo, social media icons, and three promotional banners before reaching the actual content? For someone using NVDA, that experience is multiplied tenfold. With a properly placed main landmark, the user presses a single key and jumps straight to the content.
2. nav: Your Navigation System
The nav landmark marks navigation blocks. You can have several on a page (primary navigation, secondary navigation, breadcrumbs), but each one should have an aria-label or aria-labelledby attribute to distinguish it. The HTML5 <nav> element carries an implicit role="navigation".
A common mistake I find in accessibility audits is having three <nav> elements with no label at all. A JAWS user hears "navigation, navigation, navigation" with no idea which is which. Adding aria-label="Primary navigation" and aria-label="Breadcrumbs" solves the problem in seconds.
3. header: The Orienting Banner
The header landmark, when it is a direct child of the body, becomes the site banner. This is where your logo, site name, and typically the primary navigation live. In HTML5, a <header> element directly inside the body maps to role="banner".
Be careful: a <header> inside an <article> or a <section> does not generate a banner landmark. It only does so when it is a direct child of the body or an element without a semantic role. This trips up many developers during web accessibility remediation.
4. footer: Closing Information
The footer landmark, as a direct child of the body, maps to role="contentinfo". This is where you place copyright information, legal links, contact details, and privacy policies. Like the header, it only generates a landmark when it sits at the top level of the document.
According to WebAIM's 2025 accessibility report, 68% of websites have a correctly positioned <footer>, but only 41% add descriptive labels when there are multiple footers. The difference between a correct footer and an accessible one lies in the details.
5. aside: Complementary Content
The aside landmark marks content that is related but not essential: sidebars, widgets, advertising, and related articles. In HTML5, <aside> maps automatically to role="complementary". It is important that this content makes sense outside the main flow.
Have you ever wondered why some accessible blogs place the sidebar after the main content in the DOM, even though it visually appears beside it? That is a deliberate strategy to ensure the logical tab order leads to the important content first and the complementary content second.
HTML5 to ARIA Role Mapping Table
| HTML5 Element | Implicit ARIA Role | Landmark? | How Many Per Page? |
|---|---|---|---|
| <main> | main | Yes | Exactly 1 |
| <nav> | navigation | Yes | Multiple (with aria-label) |
| <header> (child of body) | banner | Yes | 1 (top level) |
| <footer> (child of body) | contentinfo | Yes | 1 (top level) |
| <aside> | complementary | Yes | Multiple (with aria-label) |
| <section> | region (if named) | Conditional | Multiple |
| <form> | form (if named) | Conditional | Multiple |
The Skip Link: Accessibility in a Single Keystroke
A skip link is a mechanism that allows keyboard and screen reader users to bypass repetitive navigation and jump directly to the main content. WCAG 2.2 addresses this in Success Criterion 2.4.1 "Bypass Blocks" at Level A.
The implementation is straightforward: an anchor link at the very beginning of the document that points to the id of your <main> element. It is typically hidden visually and only appears when it receives keyboard focus. This benefits not only blind users but also anyone who navigates exclusively with a keyboard due to motor disabilities.
I personally consider the skip link the litmus test for basic accessibility. If your site does not have one, there are probably many other things missing as well. It is as fundamental as a seatbelt in a car: simple, inexpensive, and it saves (digital) lives.
Heading Structure and Landmarks: The Perfect Duo
Landmarks and heading structure for accessibility are two sides of the same coin. Landmarks divide the page into functional regions; headings (h1-h6) create a content hierarchy within those regions. Together, they offer two complementary navigation systems.
An NVDA user can list all landmarks with the D key or open the elements dialog with Insert+F7. They can also navigate by headings with the H key. Having both systems properly implemented is like offering both an index and a map in a book: each person chooses whichever method feels most comfortable.
The W3C recommends that every landmark contain at least one heading that describes it. That way, whether the user navigates by headings or by landmarks, they encounter the same structure. This redundancy is not a flaw; it is a feature of accessible design.
Logical Tab Order: When the Tab Key Makes Sense
Logical tab order is the sequence in which interactive elements receive focus when you press the Tab key. It should follow a natural flow: top to bottom, left to right (in LTR languages), mirroring the visual layout of the page. Landmarks help organize this flow.
A frequent mistake in web accessibility remediation is using tabindex with positive values to "fix" the tab order. This creates total chaos. The correct solution is to organize your HTML in the same order that it should be tabbed through. If your DOM follows a logical structure with well-placed landmarks, the tab order resolves itself.
WCAG 2.2 addresses this in Success Criterion 2.4.3 "Focus Order" (Level A). If the tab order does not follow a logical sequence, any keyboard user will get lost, and a screen reader will present information in a confusing order.
Common Mistakes When Implementing ARIA Landmarks
In my accessibility audits, I see these errors time and time again:
- Multiple <main> elements on the same page: only one should be visible at a time.
- Unlabeled landmarks: when there are multiple <nav> or <aside> elements, each needs an aria-label.
- Redundant ARIA roles: writing <nav role="navigation"> is redundant. The role is already implicit.
- Header and footer inside sections treated as landmarks: they only generate landmarks at the top level.
- Forgetting the skip link: the simplest and most overlooked mechanism.
- Content outside landmarks: all visible content should be inside some landmark.
According to WebAIM's Million analysis in 2025, 23% of the home pages studied lacked an identifiable main landmark, and 45% had poorly labeled landmarks. The good news is that these errors are easy to fix.
How to Verify Landmarks with Screen Readers
Verifying landmarks does not require sophisticated tools. Here is how to do it with the three most widely used screen readers:
| Screen Reader | List Landmarks | Navigate Between Landmarks | Platform |
|---|---|---|---|
| NVDA | Insert + F7 > Landmarks | D key / Shift + D | Windows |
| JAWS | Insert + Ctrl + R | R key / Shift + R (quick mode) | Windows |
| VoiceOver | Rotor (VO + U) > Landmarks | VO + Cmd + { / } | macOS / iOS |
Additionally, browser extensions like Landmarks by Matthew Tylee Atkinson (available for Chrome and Firefox) display landmarks visually overlaid on the page. It is a free and extremely useful tool for development and testing.
Frequently Asked Questions
Everything you need to know.
01
HTML5 semantic elements (,
02
Technically you can, but only one should be visible and accessible at a time. In single-page applications (SPAs), you may have multiple hidden elements and display only the one corresponding to the current view. If more than one is visible, screen readers become confused and the experience degrades significantly.
04
Not directly, but indirectly yes. Search engines like Google use semantic structure to understand page content. A well-defined helps Googlebot distinguish primary content from navigation or sidebar widgets. Furthermore, an accessible website improves user experience, reduces bounce rate, and increases time on page—all factors that Google does consider in its ranking algorithm.
05
Frameworks like Bootstrap or Tailwind CSS do not break landmarks by themselves, but the design patterns they encourage (nested divs, non-semantic components) can cause landmarks to be buried or absent. The solution is to audit the final rendered HTML, not the component source code. Tools like the Landmarks extension or the accessibility tree in Chrome DevTools show you the reality that screen readers perceive.
06
Tab order follows the DOM order, not the visual position created by CSS. If your
