WCAG 2.4.5: Multiple Ways

Why multiple ways matter

A large, deeply nested navigation menu is easy for a sighted mouse user to skim — and exhausting for many others. A screen reader user has to step through menu items one by one; a keyboard-only user has to tab through every link before the one they want; a user with low vision who zooms to 400% sees only a small slice of a mega-menu at a time. For all of them, a search box that jumps straight to the target page is dramatically faster.

The reverse is also true. Users with cognitive disabilities often find search hard to use well — it demands recalling and spelling the right keyword. For them, browsing a visible structure such as a sitemap, a table of contents, or well-organized menus is easier, because recognizing the right link is a lighter task than recalling the right word. Neither mechanism is universally better; that is exactly why the criterion asks for more than one.

Concretely, 2.4.5 helps screen reader and keyboard users skip long navigation paths, helps users with memory or attention limitations choose the mechanism that suits them, and rescues everyone from the “orphan page” problem — content that exists but can only be found if you already know its URL.

What counts as a “way”

W3C’s Understanding document for 2.4.5 lists the accepted techniques. Any two of these, each independently able to lead a user to the page, are enough to conform:

The mechanisms must be genuinely usable as routes to the page. A search box that errors out, a sitemap that was last updated three redesigns ago, or a “related links” block that omits half the site each provide zero ways, not one.

The process exception

The criterion exempts any page that is the result of, or a step in, a process. WCAG defines a process as a series of user actions where each action is required in order to complete an activity. These pages only make sense in sequence, so requiring a second route to them would be meaningless or actively harmful:

• →The shipping, payment, and confirmation steps of a checkout — you cannot pay for a cart you have not filled.
• →Step 3 of a multi-page registration or application wizard.
• →A search results page — it is the result of the search process, generated by the user's query.
• →A bank transfer confirmation screen that exists only after the user has entered transfer details.

Be careful not to stretch the exception. The entry point of a process — the product page, the “Open an account” page, the search form itself — is not a step in the process and still needs multiple ways to be found. The exception covers only the pages inside the sequence.

Pass and fail examples

Code examples

One route vs. two routes

2.4.5 is a site-architecture criterion, so the “fix” is adding a second mechanism. Here a header that offers only menus gains an accessible site search.

<!-- ✗ The menu hierarchy is the only way to reach any page -->
<header>
  <nav aria-label="Main">
    <ul>
      <li><a href="/products">Products</a></li>
      <li><a href="/docs">Docs</a></li>
      <li><a href="/support">Support</a></li>
    </ul>
  </nav>
</header>

<!-- ✓ Menus plus a labelled site search: two independent ways -->
<header>
  <nav aria-label="Main">
    <ul>
      <li><a href="/products">Products</a></li>
      <li><a href="/docs">Docs</a></li>
      <li><a href="/support">Support</a></li>
    </ul>
  </nav>
  <search>
    <form action="/search" role="search">
      <label for="site-search">Search this site</label>
      <input id="site-search" type="search" name="q" />
      <button type="submit">Search</button>
    </form>
  </search>
</header>

An HTML sitemap users can actually navigate

An XML sitemap serves crawlers, not people. A human-readable sitemap page is a plain list of links, grouped under headings that mirror the site structure, and linked from every page (typically the footer).

<!-- /sitemap — linked from the site-wide footer -->
<main>
  <h1>Site map</h1>
  <h2>Products</h2>
  <ul>
    <li><a href="/products/scanner">Accessibility Scanner</a></li>
    <li><a href="/products/monitor">Continuous Monitoring</a></li>
  </ul>
  <h2>Documentation</h2>
  <ul>
    <li><a href="/docs/getting-started">Getting started</a></li>
    <li><a href="/docs/api">API reference</a></li>
  </ul>
</main>

<footer>
  <a href="/sitemap">Site map</a>
</footer>

Related links as a second way

On content sites, a “related articles” block can be one of the two mechanisms — provided the links genuinely connect the whole set of pages, not just a favored few.

<aside aria-labelledby="related-heading">
  <h2 id="related-heading">Related articles</h2>
  <ul>
    <li><a href="/blog/alt-text-guide">How to write alt text</a></li>
    <li><a href="/blog/focus-styles">Designing visible focus styles</a></li>
    <li><a href="/blog/aria-mistakes">Five common ARIA mistakes</a></li>
  </ul>
</aside>

Common failures

• ✗Relying on the navigation menu as the only mechanism — no search, no sitemap, no index pages, no related links.
• ✗Orphan pages: content linked from nowhere on the site (email campaigns or ads only), so there are zero on-site ways to find it.
• ✗A site search that does not index all pages in the set — help articles, blog posts, or legal pages missing from results, leaving those pages with only one way.
• ✗Pointing to an XML sitemap as the second way. Crawler sitemaps are not a navigation mechanism for users; only a human-readable HTML sitemap counts.
• ✗A stale HTML sitemap that no longer reflects the site, so newer pages effectively have a single route.
• ✗Claiming the process exception too broadly — e.g. treating an entire account area or a product detail page as 'part of a process' when it is an ordinary destination page.

How to test for 2.4.5

1. 1

   Inventory the navigation mechanisms

   List every mechanism the site offers: menus, search, HTML sitemap, tables of contents, index pages, related-links blocks, breadcrumbs. You need at least two that can lead to any given page.

2. 2

   Pick sample pages and find two routes to each

   Choose a representative sample — deep pages, recent pages, and pages from each section. For each, demonstrate two genuinely independent routes: for example, reach it through the menus, then find it again via search. If any page has only one route, the criterion fails.

3. 3

   Verify the mechanisms actually work

   Search for exact titles of your sample pages and confirm they appear in results. Open the sitemap and check it includes recent content. A broken or stale mechanism does not count as a way.

4. 4

   Check for orphan pages

   Crawl the site or export the page list from your CMS and compare it against pages reachable from the homepage. Pages that only external campaigns link to are failures unless they are steps in a process.

5. 5

   Apply the process exception deliberately

   For each page you exempt, confirm it is genuinely the result of, or a step in, a sequence of required actions — checkout steps, wizard steps, search results. Entry points to those processes are not exempt.

Automated scanners cannot evaluate 2.4.5 — it is a judgment about site architecture, not any single page’s markup. Work through it as part of the full WCAG 2.2 checklist.

Frequently asked questions