WCAG 2.4.5 Multiple Ways Explained

WCAG 2.4.5 Multiple Ways is a Level AA rule that says people must have more than one way to find any page inside a set of pages — for example, a navigation menu plus a search box, or full nav plus a sitemap page. The only exception is a page that is a step in a process, like a checkout confirmation.

What WCAG 2.4.5 actually says

The normative text is short: “More than one way is available to locate a web page within a set of web pages except where the web page is the result of, or a step in, a process.” That is the entire requirement, taken from the W3C Understanding 2.4.5 document.

Two phrases carry all the weight. “More than one way” means at least two independent methods of reaching pages. “A set of web pages” means a collection that shares a purpose and is authored together — your marketing site, your blog, your store. If you have only one page, there is no set to navigate and the criterion does not apply.

The W3C lists six methods that each count as “a way,” and you need any two of them working together:

• G161 — a search function that finds content across the site
• G63 — a site map (a human-readable HTML page that links to your sections)
• G64 — a table of contents
• G125 — links that navigate to related pages
• G126 — a list of links to all other pages
• G185 — linking to all pages from the home page

A typical small business passes with a primary navigation menu (one way) plus a working search box or an HTML sitemap (the second way). The catch is that both ways must actually reach the same set of pages — a search box that only indexes blog posts does not help someone find a service page.

Who it affects, and which “way” they reach for

2.4.5 is really about a tradeoff: a navigation menu is a browse path (you scan a hierarchy until you recognize the right branch), while search is a jump path (you already know the word and type it). Some disabilities make one of those two paths slow or unusable, so the criterion’s value is letting each person pick the one that works for them. The disability does not just “affect” a generic user here — it predicts which way they will use.

• Screen reader users (JAWS, NVDA, VoiceOver) lean on search to skip the browse path. A menu is announced one link at a time, so a 30-item mega-menu is 30 stops before you even reach the submenu you want. The W3C’s own rationale is explicit: “Users with visual impairments may find it easier to navigate to the correct part of the site by using a search, rather than scrolling through a large navigation bar using a screen magnifier or screen reader” (W3C Understanding 2.4.5). Take search away and you have forced them onto the slow path.
• Cognitive-disability users lean the opposite way — toward the sitemap. Search demands that you already know and can spell the right term; that recall step is a barrier, not a help. The W3C notes “a person with cognitive disabilities may prefer a table of contents or site map that provides an overview of the site rather than reading and traversing through several web pages.” For them the HTML sitemap is the accessible way; a search-only site fails them even though it passes for the screen reader user above. That opposite preference is exactly why 2.4.5 demands two ways, not “the best one.”
• Low-vision users at high magnification can’t browse a wide menu. At 400% zoom a horizontal nav bar runs off-screen, so panning to find a link is exhausting. A search field they can tab to, or a single-column sitemap they can scroll straight down, both reach the destination without horizontal panning.
• Voice-control and switch users want the path with fewer stops. Saying “click Search” then dictating a query can be far fewer commands than driving a switch through nested submenus one focusable item at a time — provided the search field has a real accessible name to target.

Concrete failure examples — and the fix

Failure 1: Menu is the only way in. A restaurant site has a top nav and nothing else — no search, no sitemap, no comprehensive footer. That is exactly one way to locate pages, which fails 2.4.5. The fix is to add a genuine second method. An HTML sitemap is the cheapest:

<!-- /sitemap/ — a real page for humans, not the XML one for crawlers -->
<main>
  <h1>Site Map</h1>
  <nav aria-label="Site map">
    <ul>
      <li><a href="/menu/">Menu</a></li>
      <li><a href="/reservations/">Reservations</a></li>
      <li><a href="/private-events/">Private Events</a></li>
      <li><a href="/about/">About Us</a></li>
      <li><a href="/contact/">Contact</a></li>
    </ul>
  </nav>
</main>

Failure 2: An XML sitemap counted as the “second way.” A common myth. sitemap.xml is for search engines; a person using NVDA never encounters it, so it does nothing for 2.4.5. You need an HTML page or an on-page search the user can actually operate.

Failure 3: A search box that is not reachable or not labeled. If your only second way is a search field with no accessible name, keyboard users and screen reader users cannot use it — so it does not count. Give it a real label:

<form role="search" action="/search/" method="get">
  <label for="site-search">Search this site</label>
  <input type="search" id="site-search" name="q" autocomplete="off">
  <button type="submit">Search</button>
</form>

Because the second way is often a search field, 2.4.5 overlaps with accessible forms: if the input is not labeled and operable, it does not pass either rule.

How to test for 2.4.5

The test for 2.4.5 is a coverage test, not a “does an element exist” test — which is why a scanner cannot pass or fail it for you. A scanner can confirm a search input has a label, but it cannot tell whether your search box and your menu actually reach the same set of pages. That judgement is the whole point, so do it by hand against one deep page.

1. Pick the hardest page to find, not the easiest. Choose a deep leaf — a single product, a buried service, an old blog post — not the homepage. If your second way can reach that, it can reach everything shallower.
2. List the candidate ways and discard the fakes. Write down every route to that page: primary nav, footer, on-site search, HTML sitemap, related-content links. Then strike the ones that don’t truly cover the set. A footer that only links to Privacy/Terms is not a way to find a product. An XML sitemap is search-engine plumbing, not a human route — a person on NVDA never opens sitemap.xml, so it scores zero here.
3. Search the page’s own words, not its title. Type a term a real visitor would use (a product attribute, not the exact page name) and confirm the result appears. A search box that only indexes blog posts, or only matches exact titles, does not “reach” the product set even though the field renders.
4. Walk the sitemap top to bottom and confirm the leaf is on it. Open the HTML sitemap as a sighted visitor would and find the same deep page in it. A sitemap that stops at top-level sections is not a second way to that page — it’s a second way to the sections above it.
5. Run both ways keyboard-only. Unplug the mouse. Tab to the search field, type, submit; then tab through the sitemap and activate the leaf link. If either route needs a pointer, it doesn’t count — see keyboard navigation.
6. Confirm you have exactly the right scope. Step-in-a-process pages (checkout, payment confirmation, multi-step forms) are exempt by the normative text — don’t bolt navigation onto a flow to “fix” them. Everything in your authored set that isn’t a process step needs the two ways.

Real-world and lawsuit relevance

Multiple Ways is a WCAG 2.1 AA criterion. For private businesses, the DOJ has not set a binding technical standard under ADA Title III; its 2022 guidance says only that “businesses open to the public” must provide equal access and points to WCAG as “helpful guidance” rather than a mandate (ADA.gov web guidance). In practice, though, WCAG 2.1 AA is the bar plaintiffs and settlements keep referencing — and the DOJ’s 2024 Title II rule for state and local governments wrote AA into law outright (ADA.gov Title II web rule fact sheet). So while AA is not a statute for a private store, it is the yardstick a complaint will be measured against.

What makes 2.4.5 specifically lawsuit-relevant is how cheap it is to document. A tester does not need assistive tech to find the violation — they load the site, look for a search box and an HTML sitemap, and if there is only a menu, the finding writes itself in one screenshot. Digital accessibility filings have run high for years: UsableNet reports plaintiffs filed 4,187 digital accessibility lawsuits in 2024, with filings exceeding 4,000 per year since 2021 (UsableNet lawsuit tracker).

2.4.5 rarely stands alone in a complaint; it travels with the siblings that target the same “can I get around this site” problem — 2.4.1 Bypass Blocks (Level A), 2.4.6 Headings and Labels (Level AA), and 3.2.3 Consistent Navigation (Level AA). A site with only one way to find pages usually also has a menu that shifts position page to page and headings that don’t describe their sections, so one wayfinding finding tends to drag several others into the demand letter. (This page is general information, not legal advice — for your specific exposure, consult a qualified attorney.)

It is also a usability win that pays for itself: the same search box that satisfies 2.4.5 is how shoppers who already know the product name skip straight to it, which is why search-equipped sites tend to convert better — more on that in accessibility and SEO.

Fixing it the right way (not with an overlay)

The reason an overlay can’t fix 2.4.5 is structural, not cosmetic. Every other criterion an overlay claims to handle is about altering an element that already exists — recoloring text, injecting an alt attribute, forcing a focus outline. 2.4.5 asks for a second route to your content that was never built. A JavaScript widget cannot crawl your CMS, build an index, and stand up a search backend, and it cannot author an HTML sitemap of pages it doesn’t know about. There is no element on the page for it to “fix,” so it doesn’t.

Real remediation means building the missing way for real, which is concrete work in your code, not a script tag:

• If search is the second way: wire a labeled role="search" form (the labeled pattern shown above) to an actual index that covers the whole set — products, services, and posts, not just the blog — so a query for a product name returns the product.
• If the sitemap is the second way: generate the HTML sitemap from your route table or CMS so it stays complete as pages are added, list every non-process page down to the leaves, and link to it from a consistent place such as the footer so it satisfies G63 on every page.

Curbcut is deliberately anti-overlay — we build the missing search or sitemap as hand-coded remediation so the default experience conforms, and we can document the two ways in a VPAT if you need proof. Want to know whether your site already offers two real ways in? Start with a free scan and we will show you which page has only one route to it.