2.4.5 Multiple Ways
- Level AA
- Operable
- Since WCAG 2.0
Summary
People locate content in different ways. Someone with a cognitive disability may find a structured sitemap or an A-Z index far easier to work with than a deep menu hierarchy; a screen reader user may prefer typing a term into a search box over listening through nested navigation; someone with low vision using high magnification may find search faster than scanning a large menu. This criterion, at Level AA since WCAG 2.0, requires that each page in a site can be reached by more than one of these routes, so a user is never forced into the single navigation style that suits them least.
The auditor's mental model is a counting exercise. For a sample of pages across the site, count the independent ways a user could locate each one: primary site navigation, a site search, a sitemap page, an A-Z index, or lists of related links that lead to the page. Two or more independent routes is a pass. Pages that are the result of, or a step in, a process are exempt: checkout steps, wizard screens, and search results pages themselves do not need a second route, because their position in a sequence is the point. Most conventional sites pass immediately via navigation plus search; the criterion fails where content is reachable only down one deep path with no search, sitemap, or index as a second route.
Official wording
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.
EN 301 549 mapping
- Web pages
- Clause 9.2.4.5
- Software and native apps
- No software requirement: the corresponding chapter 11 clause is void in the standard.
Clause 9.2.4.5 applies this criterion to web pages unchanged. For software the standard declares the corresponding clause void, so native apps carry no mandatory equivalent: the requirement is written for sets of web pages, and equivalent sets of software programs are extremely rare.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Start by identifying the mechanisms the site offers globally: is there a main navigation menu, a site search, a sitemap page linked from the footer, an A-Z index, a category or archive listing? Two site-wide mechanisms that between them can locate every page usually settle the criterion for the whole set of pages, which is why navigation plus a working search is the most common pass.
Then verify with sample pages rather than trusting the mechanism list. Pick pages at different depths: a top-level page, a mid-level category page, and the deepest content you can find (an old blog post, a product detail page, a help article). For each, count the routes: can you reach it through the menus? Does the site search actually return it when you search for its title or distinctive content? Does the sitemap list it? Deep or orphaned content is where this fails: a PDF or landing page reachable only from one link buried three levels down, on a site with no search and no sitemap, has exactly one way and fails.
Test the search for real coverage, not just presence. A search box that only indexes blog posts does not provide a second way to reach help articles. Similarly, a "sitemap" that lists only top-level sections does not provide a second route to deep pages; it provides a second route to the sections. Finally, apply the exemption deliberately: a step 3 of 4 checkout page, a form confirmation page, or a search results page is a step in or result of a process and needs no second route. Record it as not applicable rather than passing it on a technicality.
iOS
The European standard declares this criterion void for software: it is written for sets of web pages, and equivalent sets of software programs are extremely rare, so there is no mandatory software requirement to grade a native iOS app against. In an audit scoped to the European standard, record it as not applicable for native screens rather than inventing a pass or fail.
As guidance, the underlying idea still marks out good app UX, and auditors commonly note it as a recommendation rather than a conformance result. Check whether key content is findable by more than one route: a search field alongside the tab bar or navigation hierarchy, a recents or favourites view, deep links from related content. An app where a settings option or help article can only be found by memorising one specific drill-down path is harder for everyone, and especially for users with cognitive or memory impairments. Flag it as a usability recommendation, clearly separated from WCAG findings. Note that web content rendered inside the app (a hosted help centre in a web view, for example) is still web content, and the web test above applies to it.
Android
As on iOS, the European standard declares this criterion void for software, because it targets sets of web pages and equivalent sets of software programs are extremely rare. There is no mandatory requirement to grade a native Android app against; record not applicable for native screens in audits scoped to the European standard.
As guidance, the same good-practice check applies. Look for a search affordance in the top app bar or navigation drawer alongside the primary navigation, and multiple routes to key screens: shortcuts from a home or dashboard screen, related-content links, or an in-app index for help and settings content. A single deep path to important functionality is a legitimate usability recommendation even though it is not a conformance failure. And as on iOS, any web content presented inside the app (help centres, terms pages, embedded portals) remains a set of web pages: apply the full web procedure there, where the criterion does apply.
Pass and fail examples
Passes:
- A marketing site with a header navigation menu and a site search that indexes every page: two independent ways, the standard pass.
- A documentation site with a sidebar hierarchy plus an A-Z index of every article: two ways, even without a search.
- A blog where every post is reachable from category navigation and also from a chronological archive listing every post: two ways.
- A small site of five pages where every page links to every other page: the links themselves provide multiple ways to locate each page.
- A deep product page reachable through category menus and returned by the site search when its name is queried: two verified routes.
Fails:
- A help article reachable only by one path through three levels of menus, on a site with no search, no sitemap, and no index: one way only.
- A site whose search exists but does not index its help section, where help articles are otherwise reachable only through a single nested menu path: the second way does not cover those pages.
- Landing pages linked only from individual blog posts, absent from navigation, sitemap, and search: one incidental route at best.
Not a fail under this criterion:
- A checkout payment page reachable only from the preceding basket step: it is a step in a process and exempt.
- A search results page with no other route to that exact results view: it is the result of a process and exempt.
- A wizard confirmation screen reachable only by completing the wizard: exempt as the result of a process.
- No skip link and no landmarks on a page: repeated-block bypass belongs to SC 2.4.1 Bypass Blocks, not here.
- Navigation menus that change order between pages: that is SC 3.2.3 Consistent Navigation, a different criterion; 2.4.5 only asks whether multiple routes exist.
Commonly confused with
- Bypass Blocks, SC 2.4.1. Both live in the Navigable guideline, but 2.4.1 is about skipping past repeated blocks within a page (skip links, landmarks), while 2.4.5 is about routes between pages across the site. A missing skip link is never a 2.4.5 finding.
- SC 3.2.3 Consistent Navigation. That criterion requires navigation mechanisms that repeat across pages to keep the same relative order. It grades consistency of one mechanism; 2.4.5 grades the number of mechanisms. A site can have perfectly consistent navigation and still fail 2.4.5 if navigation is the only way to find anything.
- Breadcrumbs. A breadcrumb trail helps orientation and can contribute links, but a single breadcrumb trail alone is still one way: it exposes one path to the current page, not a second independent means of locating it. Do not count navigation plus its own breadcrumb reflection as two ways.
- SC 2.4.8 Location. The Level AAA sibling asks whether users can tell where they are within the site (breadcrumbs shine there); 2.4.5 asks whether they could have arrived by more than one route. "I do not know where I am" and "there was only one way to get here" are different findings.
How AUDITSU tests this
AUDITSU's audit walkthrough handles this criterion at the site level rather than screen by screen. Early in a web audit it asks you to inventory the location mechanisms on offer (navigation, search, sitemap, index, related links), then, as you work through sampled pages, to confirm each sampled page is genuinely reachable by at least two of them, with search coverage verified rather than assumed. Process pages (checkout steps, wizard screens, results views) are recorded as not applicable with the exemption noted as evidence, so the report shows the reasoning, not just the grade.
For native iOS and Android screens, the walkthrough reflects the European standard's position that the criterion is void for software: it records not applicable for conformance and offers the multiple-routes check as an optional usability recommendation instead, keeping guidance findings clearly separated from WCAG results. Web content inside an app is routed back through the full web check.
For the full guided workflow, see the audit platform.