Level AA

At least two distinct location mechanisms (nav, search, sitemap, index, breadcrumb, related links) must reach any page in a set -- except pages that are a step in a process

2.4.5 Multiple Ways

In Plain Language

2.4.5 Multiple Ways (Level AA) requires at least two different mechanisms to locate any page within a set of web pages[1]. The qualifying mechanisms named by the W3C include a site-wide navigation bar, a search function, a site map, a table of contents, an index (A-Z or tag/category), a breadcrumb trail, related-page links, and a home page that links to every other page in a small site.

The rule applies per set of pages, not per individual page -- a persistent header nav plus a footer search box shipped across the template counts as two mechanisms for every page that uses the template. A single mechanism, no matter how well built, does not conform.

Exception: pages that are the result of, or a step in, a process are exempt. Checkout flows, multi-step wizards, tax filings, booking confirmations, and search results pages depend on the preceding step, and exposing a parallel nav or search mid-flow would let users skip state the process requires.

Why It Matters

  • Location strategy varies by user. Some readers browse hierarchically through a nav menu, some type a keyword into search, some scan a sitemap for a mental model of the whole site, some follow breadcrumbs back up a tree. A site that exposes only one of these strategies forces every user through the same funnel regardless of fit.
  • Screen-magnifier and low-vision users often prefer search to scrolling a long navigation menu: at 400% zoom, a 12-item mega-nav becomes a multi-screen scroll, while a search input is a single field[1].
  • Users with cognitive and learning disabilities may find keyword search harder than category browsing -- spelling, recall, and query formulation are barriers -- and benefit from a sitemap or tag index that lays out the content space visually.
  • Screen-reader users navigating by landmark and heading can jump faster through a structured sitemap or table of contents than through repeated traversal of a deep nav tree.
  • Multiple mechanisms also provide resilience: if the JavaScript-driven mega-menu fails to hydrate or the search index is stale, a static sitemap link in the footer still resolves.

Examples

Do: Provide search alongside navigation

✔ Users can browse via nav or find pages via search

<nav aria-label="Main">
  <a href="/">Home</a>
  <a href="/products">Products</a>
  <a href="/support">Support</a>
</nav>

<form role="search" aria-label="Site search">
  <input type="search" aria-label="Search site">
  <button type="submit">Search</button>
</form>
Don't: Only one way to navigate

✘ Navigation menu is the only way to find pages -- no search, site map, or other alternatives

Do: Include a site map page

Site Map

✔ Site map gives a complete overview of all available pages

<h1>Site Map</h1>
<ul>
  <li><a href="/">Home</a></li>
  <li><a href="/products">Products</a>
    <ul>
      <li><a href="/products/widget-a">Widget A</a></li>
      <li><a href="/products/widget-b">Widget B</a></li>
    </ul>
  </li>
  <li><a href="/support">Support</a></li>
</ul>
Don't: Deeply nested menus as sole navigation
Products >
Category A >
Sub-category 1 >
Widget X

✘ Users must drill through 4 levels to find a page -- no search or site map alternative

How to Fix It

  1. Inventory what you already have. A persistent top-nav plus a footer sitemap link already satisfies 2.4.5 for every page that uses the template. Before adding a new mechanism, confirm the existing ones are actually reachable on every non-process page and are exposed to assistive technology (landmarks, accessible names, keyboard reachable).
  2. Add site search as a second mechanism. Wrap the input and submit control in <form role="search"> with an aria-label, give the <input type="search"> its own accessible name, and expose the form in the header or a skip-linked landmark so it is not buried inside a collapsed menu.
  3. Ship a sitemap page and link it from the footer. A /sitemap page rendered as nested <ul> lists (not the XML sitemap used by crawlers) gives cognitive-accessibility users and sighted keyboard users a single hierarchical overview. Link it from the global footer so it inherits onto every page in the set.
  4. Add a tag or category index for content-heavy sites. An A-Z index, tag cloud, or category landing gives a second browse-by-topic mechanism that does not require recalling the exact hierarchy the nav imposes.
  5. Expose breadcrumbs and related-page links. Breadcrumbs (`<nav aria-label="Breadcrumb"> with an ordered list) and "See also" blocks count toward 2.4.5 and also help orientation on deep pages.
  6. Mark process pages explicitly. For pages inside a checkout, wizard, or multi-step form, the exception applies -- but identify them deliberately (a step indicator, a breadcrumb-of-steps, or a clear heading) so the missing top-level nav is a design decision, not an oversight. Do not apply the exception to the landing page of the process or to unrelated pages that happen to sit on the same template.

References

  1. [1] W3C (2023). Understanding Success Criterion 2.4.5: Multiple Ways. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/multiple-ways.html ↩ ↩