Multiple ways & consistent navigation

Finding your way around a site is its own task, separate from reading any single page. People do it differently: some scan a menu, some jump straight to a search box, some recognise a familiar link in the same corner of every page. Accessibility here is less about a single widget and more about the shape of the whole site — whether there is more than one route to a page, whether the routes stay put, and whether the same thing is named the same way wherever it appears.

When those expectations break, the cost lands hardest on people who rely on memory, orientation, or assistive technology: a screen reader user who has learned the link order, a person with a cognitive disability who recognises “Search” but not a bare magnifier icon, a keyboard user counting tab stops. This lesson covers three site-level defects and the WCAG success criteria that address each one.

What you’ll learn

Why a set of pages needs more than one way to reach each page — such as a search and a sitemap alongside the menu (2.4.5); why repeated navigation must appear in the same relative order on every page it occurs (3.2.3); and why a component with the same function must carry a consistent label and name everywhere it is used (3.2.4). These are AA criteria, and the fixes are about structure and discipline, not extra ARIA.

Standards this lesson maps to
Standard Criterion Level What it requires
WCAG 2.2 2.4.5 Multiple Ways AA More than one way is available to locate a page within a set of pages, except where the page is a step in a process.
WCAG 2.2 3.2.3 Consistent Navigation AA Navigational mechanisms repeated across pages appear in the same relative order each time, unless the user changes it.
WCAG 2.2 3.2.4 Consistent Identification AA Components with the same functionality across a set of pages are identified consistently (same name and label).
WCAG 2.2 2.4.6 Headings and Labels AA Headings and labels describe their topic or purpose, which supports finding and recognising controls.
EN 301 549 9.2.4.5 / 9.3.2.3 / 9.3.2.4 (incorporates WCAG) — European harmonised standard; references the WCAG A/AA set including these navigation criteria.
Section 508 502.3 / 504 (incorporates WCAG A & AA) — US federal ICT must meet WCAG 2.0 Level A and AA, including Multiple Ways and consistency.
ADA Title II WCAG 2.1 AA (DOJ rule) AA US state/local government web content must conform to WCAG 2.1 AA.

The three problems we’ll fix

Each card below isolates one common site-level defect. For every issue you get a plain-language statement of the problem, a Bad example (shown as escaped, non-running code so it can’t harm this page), a Good example, the copyable Code, and an ordered fix.

Only deep menus — no search or sitemap

WCAG 2.2 · 2.4.5 AA EN 301 549 Section 508 ADA Title II

When the only route to a page is a multi-level dropdown menu, anyone who can’t hold the whole hierarchy in mind, or can’t operate a hover-revealed flyout, is stuck. Multiple Ways asks for at least two independent ways to locate a page within the set — so the menu can stay, but it must be backed by something like a site search, a sitemap, an A–Z index, or a clear set of in-page links. The two ways must be genuinely different mechanisms; two menus that lead to the same place don’t count. The one exception is a page that is a step inside a process (a checkout step, a wizard), where extra routes could let people skip required steps.

Bad

The deep menu is the sole way in. There is no search and no sitemap, so a page buried three levels down has exactly one path to it (2.4.5).

bad-single-route.html 
<nav aria-label="Primary">
  <ul>
    <li>Products
      <ul><li>Hardware
        <ul><li><a href="/products/hw/sensors">Sensors</a></li></ul>
      </li></ul>
    </li>
  </ul>
</nav>
<!-- No search, no sitemap, no index: one route only -->

Good

The same menu is kept, but a site search and a link to a full sitemap give two more independent ways to reach any page.

good-multiple-ways.html 
<form role="search" action="/search">
  <label for="site-search">Search the site</label>
  <input type="search" id="site-search" name="q">
  <button type="submit">Search</button>
</form>

<a href="/sitemap">Sitemap</a>
<!-- Menu (above) + search + sitemap = three ways in -->

Code

A sitemap page is just a structured, hierarchical list of links to the real pages — easy to scan, fully keyboard-reachable, and a second mechanism in its own right.

sitemap.html 
<main>
  <h1>Sitemap</h1>
  <ul>
    <li><a href="/products">Products</a>
      <ul>
        <li><a href="/products/hw/sensors">Sensors</a></li>
        <li><a href="/products/sw/dashboard">Dashboard</a></li>
      </ul>
    </li>
    <li><a href="/support">Support</a></li>
  </ul>
</main>

How to fix

  1. Provide at least two independent ways to find any page: keep the menu and add a site search, a sitemap, an A–Z index, or related-links.
  2. Make sure the two ways are genuinely different mechanisms — a duplicate menu doesn’t satisfy 2.4.5.
  3. Build the search as a real role="search" landmark with a labelled input so it’s easy to find and operate.
  4. Exclude only pages that are steps in a process (checkout, multi-step forms), where alternate routes would let users skip steps.

Navigation re-ordered between pages

WCAG 2.2 · 3.2.3 AA EN 301 549 Section 508 ADA Title II

People build a mental map of a site from its repeated navigation: “About is the fourth link”, “Contact is last”. Consistent Navigation requires that any navigation repeated across pages keeps the same relative order each time it appears. If the order is shuffled from page to page — alphabetised on one, sorted by popularity on the next — that map breaks, and the cost falls on screen reader and keyboard users who navigate by position, and on people with cognitive disabilities who rely on familiarity. Adding or removing an item is fine; what matters is that the items that remain stay in the same relative sequence. The only allowed reordering is one the user initiates.

Bad

The same five links appear on both pages, but the order is different. A user who learned the sequence on the home page can’t rely on it elsewhere (3.2.3).

bad-reordered-nav.html 
<!-- home.html -->
<nav aria-label="Primary"><ul>
  <li><a href="/">Home</a></li>
  <li><a href="/products">Products</a></li>
  <li><a href="/about">About</a></li>
  <li><a href="/contact">Contact</a></li>
</ul></nav>

<!-- about.html — same links, different order -->
<nav aria-label="Primary"><ul>
  <li><a href="/about">About</a></li>
  <li><a href="/contact">Contact</a></li>
  <li><a href="/">Home</a></li>
  <li><a href="/products">Products</a></li>
</ul></nav>

Good

The relative order is identical on every page. The current page may be marked with aria-current="page", but its position in the list does not move.

good-consistent-nav.html 
<!-- Identical order on home.html AND about.html -->
<nav aria-label="Primary"><ul>
  <li><a href="/">Home</a></li>
  <li><a href="/products">Products</a></li>
  <li><a href="/about" aria-current="page">About</a></li>
  <li><a href="/contact">Contact</a></li>
</ul></nav>

Code

Render navigation from one shared, ordered source — a partial or component — so every page emits the same sequence. Items may be conditionally hidden, but never re-sorted per page.

nav-from-source.html 
<!-- Single ordered list, included on every page -->
<!-- nav-items: Home, Products, About, Contact (fixed) -->
<nav aria-label="Primary">
  <ul>
    <!-- loop renders items in declared order, every page -->
    <li><a href="{{url}}"
      {{#if current}}aria-current="page"{{/if}}>{{label}}</a></li>
  </ul>
</nav>

How to fix

  1. Define each repeated navigation block once and render it from that single ordered source on every page.
  2. Keep the relative order of items fixed; mark the current page with aria-current="page" instead of moving it.
  3. You may add or remove items between pages — just don’t re-sort the ones that remain.
  4. Allow reordering only when the user chooses it (for example a “customise menu” feature), never automatically per page.

The same control labelled differently on different pages

WCAG 2.2 · 3.2.4 AA 2.4.6 AA EN 301 549 Section 508 ADA Title II

Consistent Identification asks that a component which does the same thing across a set of pages be identified the same way every time. If a search button reads “Search” on one page, “Find” on another, and is a bare magnifier icon with the accessible name “Submit” on a third, users can’t tell it’s the same control. This hits screen reader users — who hear the accessible name, not the icon — and people with cognitive disabilities, who recognise a control by its wording. The text, the icon’s alternative text, and the accessible name all have to agree, and stay the same wherever the control appears.

Bad

The same “add to cart” action is named three different ways across pages, and one version is an icon whose accessible name doesn’t match the others (3.2.4).

bad-inconsistent-label.html 
<!-- product page -->
<button>Add to cart</button>

<!-- listing page — different wording -->
<button>Buy now</button>

<!-- promo page — icon only, mismatched name -->
<button aria-label="Purchase">
  <img src="cart.svg" alt="">
</button>

Good

The control carries the same visible text and the same accessible name on every page, so it is recognisably one control doing one job.

good-consistent-label.html 
<!-- Same label and accessible name on every page -->
<button>Add to cart</button>

<!-- If an icon is shown, it carries the same name -->
<button>
  <img src="cart.svg" alt=""> Add to cart
</button>

Code

When an icon-only button is unavoidable, give it the same accessible name as its text counterpart with aria-label, and keep that name in step with every other instance of the control.

icon-button-name.html 
<!-- Icon-only, but same accessible name as the text button -->
<button aria-label="Add to cart">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

<!-- Reuse one component so the name can't drift -->
<!-- <AddToCartButton /> -->

How to fix

  1. Decide on one label and one accessible name for each repeated control, and use them everywhere that control appears.
  2. Keep the visible text, any icon’s alternative text, and the accessible name consistent with each other (2.4.6, 3.2.4).
  3. For icon-only versions, give the same aria-label as the text version so the names match across pages.
  4. Build the control as a single shared component so its label can’t drift between pages over time.

Recap

  • Offer more than one way to reach a page — typically the menu plus a search, a sitemap, or a clear A–Z or index — unless the page is a step in a process (2.4.5).
  • Keep repeated navigation in the same relative order on every page; reorder by user choice only, never per page (3.2.3).
  • Give a control that does the same job the same accessible name and visible label everywhere it appears (3.2.4).

The same discipline satisfies WCAG, EN 301 549, Section 508, and ADA Title II at once — build the site’s structure consistently and you meet them all.