Search topics
Navigation landmarks that all sound the same
A shop page has three nav elements, two with no name and one named “Footer navigation”, so a screen reader's landmark list reads “navigation” twice and then “Footer navigation navigation”.
<nav> The problem
Screen reader users can't tell the page's navigation areas apart, so they can't jump straight to the one they need.
A shop's listing page has three sets of links. The header has the main menu: Shop, Journal and About. A sidebar headed "Categories" lists Kitchen, Bags and Stationery. The footer has a column headed "Help" with Delivery, Returns and Contact. Each set is in a nav element, as it should be. A screen reader user who wants the returns policy opens the landmark list, which screen readers offer so people can jump to an area of the page, and hears "banner", "navigation", "navigation", "main", "content information" and "Footer navigation navigation". Two entries are indistinguishable, the third repeats itself, and none of them says "Help". The only way to find the returns link is to visit each one.
A nav element is a navigation landmark, and a screen reader lists each landmark by its name followed by its role. The header and sidebar navs have no name, so only the role is read. The footer nav was given aria-label="Footer navigation": the role is added to the name, so "navigation" is read twice. The label also describes where the nav is, not what it holds, and ignores the visible heading, "Help", that sighted shoppers use. 1.3.1 needs the structure people see to be available in code. WCAG technique ARIA11, which uses landmarks to meet 1.3.1, checks that each landmark used more than once has a unique, meaningful name, and that is the part that fails here.
The visual page has no problem at all: three link groups in three distinct places, two of them with headings. The failure is only in the names that the code exposes for them.
2 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (not affected)
- Seizures (not affected)
- Without vision Screen reader users open the landmark list to jump to the part of the page they want. With three entries named “navigation”, they have to try each one to find the categories or the help links.
- Limited vision People who use a screen reader alongside magnification often move by landmarks to avoid panning across a large page, and lose that shortcut when the names don't say which navigation is which.
axe's landmark-unique flags two landmarks of the same role with the same name, or both with no name, but axe classes it as best practice, so many audits don't report it, and it says nothing about a name that repeats the role or misses the heading. A quick AI fix often names every nav "navigation", "nav menu" or "Main navigation", which is unique but no help, or puts the aria-label on the ul inside the nav, where a list can't carry it. Another often wraps every section in a name, so the landmark list fills with regions nobody wants to jump to. Whether each name says what its area holds is something a person has to judge.
Try it
Use the landmark list to reach the help links.
The list shows what a screen reader lists for this page. Choose an entry to jump to it. Can you tell which one holds Returns before you try?
Broken Can you fix this?
New in: kitchen linen
12 products
Screen reader’s landmarks list:
A recreated demo. The broken version is intentionally inaccessible.
The fix
Name each repeated landmark after what it holds, from its visible heading where it has one.
- 1Every landmark role used more than once gets a unique name on each instance.
- 2Name a landmark after what it holds, in a word or two, without the role.
- 3Take the name from a visible heading with aria-labelledby where there is one.
<header> <a href="/" class="logo">Fern & Fold</a> <nav> <ul> <li><a href="/shop">Shop</a></li> <li><a href="/journal">Journal</a></li> <li><a href="/about">About</a></li> </ul> </nav></header><div class="layout"> <nav class="sidebar"> <h2>Categories</h2> <ul>…Kitchen, Bags, Stationery…</ul> </nav> <main>…</main></div><footer> <nav aria-label="Footer navigation"> <h2>Help</h2> <ul>…Delivery, Returns, Contact…</ul> </nav></footer>An aria-label on each nav
<header> <a href="/" class="logo">Fern & Fold</a> <nav aria-label="Main"> <ul>…Shop, Journal, About…</ul> </nav></header><div class="layout"> <nav class="sidebar" aria-label="Categories"> <h2>Categories</h2> <ul>…Kitchen, Bags, Stationery…</ul> </nav> <main>…</main></div><footer> <nav aria-label="Help"> <h2>Help</h2> <ul>…Delivery, Returns, Contact…</ul> </nav></footer>Two navigation landmarks have no name, and the third is named for its position with the role added, so the landmark list can't tell them apart.
Each nav now has a short name that says what it holds, without the role, so the landmark list reads "Main navigation", "Categories navigation" and "Help navigation". It is one attribute per nav and easy to set from a component prop. The sidebar and footer names copy their headings, so the two have to be changed together, and some page translators leave aria-label untranslated while the headings beside it change language.
Both give each navigation a unique name and meet ARIA11 for 1.3.1, so the first option is not wrong. Where a landmark has a visible heading, point at the heading anyway, for two reasons.
The text is written once. With aria-label, "Categories" lives in the heading and again in the attribute. When someone renames the heading to "Shop by room", nothing reminds them of the label, and screen reader users go on hearing "Categories", a name nobody else can see.
The name is translated with the page. Browser page translation changes the heading text but often skips aria-label, so on a translated page the landmark list keeps the original language beside translated headings. A name taken from the heading is the heading, so it changes with it.
Keep aria-label for landmarks with no visible heading, like the header nav here, and where a shared component can't take an id for its heading.
Leave the role out of the name. Screen readers add the role themselves, so "Main navigation" is enough, written as aria-label="Main". The same goes for "region", "menu" and "landmark". Name what the area holds, in a word or two, as you would in a sentence.
Landmarks that appear once need no name. A page normally has one header at the top level (banner), one main and one footer (content information), and these need no name. Name a landmark when its role appears more than once, for example several nav or aside elements, or a search element in the header and another on a results page.
A named section is a landmark. A section element becomes a region landmark only when it has a name, so a label on every section floods the landmark list. Name only the few areas people would want to jump to, and let headings do the rest.
Identical navigations can share a name. When the same pagination appears above and below a results list, the two navs hold the same links. The ARIA Authoring Practices allow them the same name, such as "Pagination", because either one does the job.
Put the name on the landmark. The name goes on the nav, aside, section or form itself. A ul, a div with no role or a heading inside the landmark can't pass its name up, and a label on a div with no role is ignored by many screen readers.
Components. A shared navigation component used in several places needs a required name prop, or an id for its heading, so every instance gets a different name. Check the rendered page, not the component on its own.
Fixing this with an AI coding assistant? Get this guide as Markdown
Verify the fix
3 checks, no mouse.
Test with: Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat whenever a navigation is added or a shared layout changes.
Limits
This is a starting pattern, not a guarantee for every application. Paths, class names and the … in the lists are placeholders. Screen readers word the landmark list differently, and some read the role before the name, so listen for the names rather than the exact phrasing. This guide covers naming landmarks, not whether a page has the right landmarks in the first place, or content left outside them. Test the complete journey with your target assistive technology.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
References
- WCAG Understanding: info-and-relationships (opens in a new tab)
- WCAG Technique ARIA11 (opens in a new tab)
- ARIA APG: landmark-regions (opens in a new tab)
- developer.mozilla.org: aria-label (opens in a new tab)
- developer.mozilla.org: nav (opens in a new tab)
- dequeuniversity.com: landmark-unique (opens in a new tab)
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.