WCAG 2.4.5 — Multiple Ways

What this requires

More than one way to locate a web page within a set of pages must be available, except when the page is the result of, or a step in, a process. The criterion targets sites larger than a couple of pages: typical mechanisms include site-wide search, a sitemap or HTML table of contents, a hierarchical navigation menu, breadcrumbs, or clusters of related-content links.

How AI coding tools fail this

When asked to "build a docs site" or "set up a marketing site", AI tools typically ship with one navigation mechanism — a top nav with a handful of links — and consider the navigation problem solved. There's no sitemap, no search, and no internal linking strategy beyond what fits in the header.

The second pattern: search that exists but is hard to find. A search input nested in the user account menu, or a /search page with no link to it from the navigation. Search counts as a way only if users can reach it.

The third: a sitemap that exists for SEO (/sitemap.xml) but nothing equivalent for humans. The criterion is about user navigation, not crawler indexing.

Failing examples

A multi-page site with only a top-nav of five links and nothing else:

<nav aria-label="Primary">
  <ul>
    <li><Link href="/">Home</Link></li>
    <li><Link href="/about">About</Link></li>
    <li><Link href="/services">Services</Link></li>
    <li><Link href="/blog">Blog</Link></li>
    <li><Link href="/contact">Contact</Link></li>
  </ul>
</nav>

Passing examples

Pair top-nav with a discoverable search and an HTML sitemap page in the footer:

<>
  <nav aria-label="Primary">
    <ul>{/* main nav */}</ul>
  </nav>
  <form action="/search" role="search">
    <label htmlFor="site-search" className="sr-only">Search the site</label>
    <input id="site-search" type="search" name="q" />
    <button type="submit">Search</button>
  </form>
  <footer>
    <Link href="/sitemap">Site map</Link>
  </footer>
</>

For docs and content sites, breadcrumbs and a per-page table of contents add another mechanism:

<nav aria-label="Breadcrumb">
  <ol>
    <li><Link href="/docs">Docs</Link></li>
    <li><Link href="/docs/guides">Guides</Link></li>
    <li aria-current="page">Getting started</li>
  </ol>
</nav>
<aside aria-label="On this page">
  <ol>{/* TOC entries */}</ol>
</aside>

Edge cases

Process steps are exempt. A checkout flow with five sequential pages doesn't need three navigation mechanisms — the path is linear by design.
Single-page sites are exempt. The criterion targets "set of pages" with more than a handful.
Search is the strongest single mechanism for users who know what they're looking for. Sitemap is the strongest for exploration.
Breadcrumbs count toward the criterion and help orient users (2.4.8).
Footer navigation that mirrors the header doesn't usually count as a second mechanism — same links, different placement.

How Jeikin handles this

This is a site-level review item. The dashboard records which mechanisms are present on a site (top nav, search, sitemap, breadcrumbs, TOC) and confirms at least two are reachable from the common pages. The scanner flags pages where the search input is missing from the header but present elsewhere as a discoverability warning.

References

W3C — Understanding 2.4.5 Multiple Ways (opens in new tab)