Multiple Ways to Find Content: What WCAG SC 2.4.5 Requires for E-Commerce Navigation

Quick answer: WCAG SC 2.4.5 Multiple Ways (Level AA) requires that most pages on a site be reachable in more than one way — through category navigation and site search, for example, not just one or the other. The one carve-out is a page that’s “the result of, or a step in, a process,” like an order-confirmation screen or a set of search results themselves — those are exempt because there’s no meaningful second path to something that only exists because you just did the thing that produced it. The practical test for a store: pick any category or product page and ask whether a shopper could still find it with the main nav menu turned off. If the only path is one link buried in a homepage banner, that’s the failure this criterion is written to catch.

This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA is a technical-practice standard, not a legal determination — consult qualified counsel for legal risk questions.

What the criterion actually says

The normative text, quoted directly from the W3C Understanding doc:

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.

The doc’s own “In Brief” summary states the goal plainly: “Users can get to content in multiple ways.” What to do: “Provide at least two options for reaching the same content.” The Intent section explains why this is phrased as options rather than a single prescribed navigation scheme:

The intent of this success criterion is to make it possible for users to locate content in a manner that best meets their needs. Users may find one technique easier or more comprehensible to use than another.

The doc names specific reasons different users need different paths: someone using a screen magnifier or screen reader may find a search box faster than scrolling a large nav bar; someone with a cognitive disability may prefer a site map over a hierarchy of category pages; someone else may prefer moving through content sequentially rather than jumping around. No single pattern serves everyone, so the criterion doesn’t pick one — it requires a second option alongside whichever one you built first.

Six accepted techniques — you need at least two, in combination

The Understanding doc lists six Sufficient Techniques and is explicit that no single one is enough on its own: you satisfy the criterion by “using two or more of the following techniques” together.

• G125 — links to related web pages — category/sub-category nav, related-product links, footer links. Most sites have this by default.
• G64 — a table of contents — more relevant to long-form buying guides than a storefront’s main nav.
• G63 — a site map — a page linking to the site’s sections, linked to from every page it lists.
• G161 — a search function — quoted directly, a search function “offers users a way to find content… without needing to understand or navigate through the structure of the website.”
• G126 — a list of links to all other web pages — a full-site link index, distinct from a hierarchical site map.
• G185 — linking to every page from the home page — sufficient alone for a very small site, per the doc’s own five-page-local-business example.

For a typical store, the realistic pair is category/nav links (G125) plus search (G161), sometimes backed by a footer site map (G63). Most stores with a working nav menu and a working search box already clear this bar without doing anything deliberate. Where they actually fail is when one of those two paths quietly breaks for a specific page or section — nobody notices, because the other path is still working everywhere else.

The exception, and why it’s checkout-shaped

The process exception has two of its own worked examples in the Understanding doc, and both describe the same shape: a page that exists because of an action the user just took, with no independent path to it.

Where content is a result of a process or task - Funds transfer confirmation: An on-line banking site allows fund transfer between accounts via the web. There is no other way to locate the confirmation of fund transfer until the account owner completes the transfer.

Where content is a result of a process or task - Search engine results: A search engine provides the search results based on user input. There is no other way to locate the search results except to perform the search process itself.

An order-confirmation page after checkout is the direct e-commerce analog of the first example — there’s no second navigation path to “your receipt for the order you just placed,” because that page didn’t exist until you placed it. The same logic covers individual checkout steps themselves: cart, shipping, payment, and review are each a step in one process, not independent destinations someone should be able to reach some other way. That’s a separate question from whether each step is labeled clearly, which is what aria-current="step" addresses — 2.4.5 only concerns itself with whether a second path to the page needs to exist at all, and here it doesn’t.

Search-results pages get the same exemption for the same reason: the results page for “blue running shoes” is a byproduct of the query, not a page a store needs a second route into. What the exception does not cover is everything upstream of the process — the category page, the product page, the collection landing page a shopper reaches before starting checkout. Those still need two real paths in.

Where this actually breaks on e-commerce sites

The failure pattern isn’t usually “no navigation exists.” It’s a page that’s reachable exactly one way, and nobody noticed because the rest of the site works fine.

A seasonal collection page linked only from a homepage banner. Marketing spins up “Summer Sale,” links it from a rotating hero banner, and never adds it to permanent category navigation. Once the banner rotates off, the page still exists for anyone with the direct link, but has no path in from anywhere else — and if the search index excludes ungrouped landing pages, it has zero paths for anyone browsing normally.

A category that’s in the mega menu but not the footer or site map. Fine on its own, until it’s the only path, because the footer link list and sitemap page were built once, early, and never kept in sync as categories shipped. If the mega menu breaks — a script conflict, a mobile viewport where the flyout doesn’t render — the category has no fallback route.

Search that doesn’t actually index the page. A search box existing isn’t the same as G161 being satisfied for a given page. If the index is built from product titles and descriptions only and never returns a category-landing page, search isn’t a real second path for that page, whatever the nav situation is.

The fix is the same in every case: check each non-process page against the “at least two” bar individually, not the site as a whole. A site can have a good mega menu and a well-built search autocomplete and still fail this criterion for specific pages those mechanisms don’t actually reach.

A quick manual check

1. Pull a list of every non-process page — category, sub-category, collection, and product pages. Skip cart/checkout steps and order confirmations; they’re exempt.
2. For each page, ask: is it linked from a persistent navigation element (main nav, mega menu, footer, or a site map page)? Not a banner that rotates off, not a one-off email link.
3. Then ask: does the site’s own search return this page for a reasonable query someone would actually type? Test it — don’t assume the index covers everything.
4. Flag any page where the answer to both is no, or where the only “yes” is a link that’s likely to disappear (a seasonal banner, a since-expired promo).

FAQ

Does having a search box automatically satisfy this criterion? Not by itself, and not for every page. A search function is one of the six accepted techniques, but it only counts for a given page if that page is actually indexed and returned by the search. It has to be paired with at least one other technique (typically nav links) to satisfy the criterion overall.

Do individual product pages need two separate navigation paths? Generally yes, unless a product page is itself the direct result of a process (it isn’t, in the normal browsing case) — a product should be reachable via category navigation and via search, at minimum.

Is a breadcrumb trail one of the six techniques? Not directly — breadcrumbs help you understand where you are once you’ve arrived, which is closer to SC 2.4.8 Location (Level AAA, not required for AA conformance) than to 2.4.5’s “how did you get here” question. A useful extra signal, but not one of the six techniques above.

Get a human-reviewed audit, not just a scan

An automated scanner checks a page in isolation — it has no way to know whether that page has a second way in from somewhere else on the site, because that’s a structural question about the whole site, not something visible from one URL. Quietramp’s audits pair an automated scan with a manual review of your site’s actual navigation and search paths, delivered as a prioritized, developer-actionable PDF report. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.

---

This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.