# Navigation landmarks that all sound the same

Source: https://easeweb.dev/learn/landmark-names
Topics: Page structure > Landmarks mark the main areas (WCAG 1.3.1)
The fix: Give every landmark that appears more than once its own short name, without the role in it. Either add an aria-label to each nav, or name the ones that have a visible heading with aria-labelledby pointing at it and add an aria-label only to those without one.
Test with: screen reader
References: https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html https://www.w3.org/WAI/WCAG22/Techniques/aria/ARIA11 https://www.w3.org/WAI/ARIA/apg/practices/landmark-regions/ https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-label https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/nav https://dequeuniversity.com/rules/axe/4.10/landmark-unique

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.

## What happens

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.

## Why it fails

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.

## Who is affected

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.

## What automation and AI miss

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.

## Before: navs with no name, and one that repeats its role

```html
<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>
```

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.

## After: an aria-label on each nav

```html
<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>
```

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.

## After: name navs after their visible headings

```html
<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-labelledby="categories-heading">
    <h2 id="categories-heading">Categories</h2>
    <ul>…Kitchen, Bags, Stationery…</ul>
  </nav>
  <main>…</main>
</div>
<footer>
  <nav aria-labelledby="help-heading">
    <h2 id="help-heading">Help</h2>
    <ul>…Delivery, Returns, Contact…</ul>
  </nav>
</footer>
```

The sidebar and footer navs take their names from the headings people already see, through `aria-labelledby`, and only the header nav, which has no heading, keeps an `aria-label`. The landmark list reads the same as before. The names now change whenever the headings change, and they are translated with the page, because they are the page's own text.

## Which option to use

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.

## Implementation decisions

**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.

## Verify the fix

1. In the browser's accessibility tree, list the landmarks and check that every navigation has a name, that no two navigations share a name unless they hold the same links, and that no name contains "navigation". Where a nav has a visible heading, check that its name is that heading.
2. Open a screen reader's landmark list (in NVDA, Insert + F7 and choose Landmarks; in VoiceOver, the rotor) and check that each navigation can be told apart by its name alone and that each name says what it holds. Move to each one and confirm it lands on the links you expected.
3. Turn on the browser's page translation and open the landmark list again: names taken from headings should be translated. Where a component is used twice, check both instances have their own names on the rendered page.

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.