aria-label or aria-labelledby. Otherwise screen reader users get a landmark list that reads "navigation, navigation, navigation, navigation" and have to open each one to find out what it is.Landmarks in one minute
Landmarks are the regions assistive technology uses to map a page: banner (your header), navigation (nav), main, complementary (aside), contentinfo (your footer), search, form, and region. Screen reader users pull up a landmark list, the rotor in VoiceOver or the D key and elements list in NVDA, and jump straight to the section they want instead of tabbing through two hundred links. It is the power-user way to move through a page, and it only works if the map has readable labels.
The duplicate problem
Modern templates ship several navs, and that is perfectly valid HTML: the main menu in the header, a breadcrumb trail, maybe an in-page table of contents, pagination under the listing, and a fat footer full of links. The trouble starts in the landmark list. Unlabeled, every single one of those announces as just "navigation". Four entries all called "navigation" is like a drawer of unlabeled keys: the user has to try each one to learn what it opens. That is not navigation, it is trial and error.
axe-core flags this as landmark-unique: landmarks sharing the same role must be distinguishable by their accessible name. One nav on a page needs no label at all. The second nav is the moment labels stop being optional.
The fix: label every duplicate
Add aria-label to each same-type landmark: <nav aria-label="Main">, <nav aria-label="Breadcrumb">, <nav aria-label="Pagination">, <nav aria-label="Footer">. Done. A few rules I hold to, learned the mildly annoying way:
- Never repeat the role in the label. Screen readers append the role themselves, so
aria-label="Main navigation"gets announced as "Main navigation navigation". "Main" is enough. - Keep it to a word or two. Labels are wayfinding signs, not descriptions.
- Prefer
aria-labelledbywhen a visible heading already names the region. An aside headed "Related articles" can point at that heading's id; the label then stays in sync with the UI and gets translated with the content. - Remember that
aria-labeldoes not translate itself. If the site is multilingual, those strings need to run through the same localization pipeline as everything else. Hardcoded English labels on a French page are their own little failure. - Only duplicates need this. A page with a single nav is fine unlabeled; the rule fires when types collide.
One structural note: banner and contentinfo should exist once per page at the top level. If an audit shows two banners or two footers, you have a template problem to fix, not a labeling problem to paper over.
Where duplicates come from, and what to call them
| Landmark role | HTML element | Common duplicate scenario | Example labels |
|---|---|---|---|
| navigation | nav | Header menu, breadcrumb, pagination, footer links | "Main", "Breadcrumb", "Pagination", "Footer" |
| complementary | aside | Related posts sidebar plus an ad or promo rail | "Related articles", "Sponsored" |
| region | section with an accessible name | Several promoted feature sections on one page | Name each, or demote extras to plain divs |
| search | search element or role="search" | Site search in the header plus an on-page filter | "Site", "Filter results" |
| form | form with an accessible name | Newsletter signup plus contact form on one page | "Newsletter signup", "Contact" |
How to detect it
axe DevTools flags landmark-unique and points at the exact elements, which makes the dev handoff trivial. Accessibility Insights for Web has a landmarks visualization that draws colored overlays on the live page; it is the fastest way I know to actually see a page's landmark structure, and I use it in almost every audit. For scale, Screaming Frog with accessibility checks enabled (version 20 onward) surfaces the issue across a full crawl, so you learn which templates are affected rather than which URLs. Close the loop the honest way: open the landmark list in VoiceOver or NVDA and read your own map. If you cannot tell your navs apart in that list, neither can anyone else.
Why an SEO should bother with this one
Straight answer: there is no evidence labeled landmarks are a ranking input, and I will not pretend otherwise. The reason this lives in my audits anyway is that landmark structure mirrors the semantic HTML that search engines lean on to separate boilerplate from primary content. Sites failing this check often turn out to have div-soup templates, duplicated header markup, or navigation rendered in odd ways, all things worth catching. There is also a compliance clock ticking for a lot of businesses: the European Accessibility Act's June 2025 deadline pulled accessibility conformance onto roadmaps that had ignored it for years, and this particular fix is about the cheapest, most visible win on the list. Two attributes per template and your Lighthouse accessibility report gets greener.
DO
- Label every landmark type that appears more than once
- Point
aria-labelledbyat a visible heading when one exists - Keep labels short, specific, and free of the role word
- Run label strings through your localization pipeline
- Verify with a landmark overlay or a real screen reader
DON'T
- Don't write "navigation" inside a nav's label; it gets announced twice
- Don't promote every section to a region and drown users in landmarks
- Don't give two same-type landmarks identical labels; that defeats the point
- Don't ship two banner or two contentinfo landmarks; fix the template
- Don't assume a theme update kept your labels; re-test after upgrades
Questions that come up
Is this an actual WCAG failure?
aria-label or aria-labelledby, which should I use?
Do I need role="navigation" on a nav element?
How many landmarks is too many?
Does this affect my rankings?
A messy landmark map usually means a messy template.
I audit semantic structure, accessibility, and crawlability in one pass, so you fix the template once instead of chasing symptoms three times.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
