Requires more than one way to find a page within a set of pages, such as navigation, search or a site map, except for pages in a process.
People look for information in different ways. Some know what they want and type it into a search box. Some browse a menu. Some want an overview of the whole site. A site that offers only one route leaves out those for whom that route does not work, for example someone who cannot use a complex menu, or who cannot spell the term to search for.
This criterion requires that more than one way is available to locate a web page within a set of web pages, except where the page is the result of, or a step in, a process.
People who cannot use one of the ways: someone with a cognitive disability who finds a deep menu confusing, someone with dyslexia who cannot spell a search term, a screen reader user for whom a site map is faster than a mega menu, a person on a small screen who prefers search. Anyone who is lost on a large site.
The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Several ways to find content are part of "operable".
The technical counterpart is the standard EN 301 549, which incorporates WCAG 2.4.5 by reference and turns it into separate clauses for each kind of ICT.
| Clause | Type of ICT | What it requires |
|---|---|---|
| 9.2.4.5 | Web pages | Web content must satisfy WCAG success criterion 2.4.5. |
In EN 301 549 V3.2.1 the software clause did not carry this criterion, because it concerns sets of web pages. Check whether V4.1.1 changes that. Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.
Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 2.4.5 is the same in WCAG 2.1 and 2.2. It is a Level AA criterion.
A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.
Directive (EU) 2019/882, EUR-Lex, opens in a new tab
The simplest way to satisfy the criterion on most sites is main navigation plus a search function.
TR<nav aria-label="Main">…</nav>
<!-- no other way to find pages --><nav aria-label="Main">…</nav>
<form role="search" action="/search">
<label for="q">Search the site</label>
<input id="q" type="search" name="q">
<button>Search</button>
</form>A page that lists the structure of the site is a second way, and also helps search engines.
<footer><a href="/">Home</a></footer><footer>
<a href="/sitemap">Site map</a>
</footer>
<!-- /sitemap -->
<h1>Site map</h1>
<ul>
<li><a href="/products">Products</a>
<ul><li><a href="/products/shoes">Shoes</a></li></ul>
</li>
<li><a href="/support">Support</a></li>
</ul>Anchor links give users a quick route inside a long document.
<h2>Installation</h2>
<h2>Configuration</h2><nav aria-label="On this page">
<ul>
<li><a href="#install">Installation</a></li>
<li><a href="#config">Configuration</a></li>
</ul>
</nav>
<h2 id="install">Installation</h2>
<h2 id="config">Configuration</h2>Links to related pages give a third way and help users who found a page but need a neighbour.
<article>…</article><article>…</article>
<aside aria-labelledby="rel">
<h2 id="rel">Related guides</h2>
<ul>
<li><a href="/guides/contrast">Contrast basics</a></li>
</ul>
</aside>On a small site, a list of all pages on the home page is enough.
<main><h1>Welcome</h1></main><main>
<h1>Welcome</h1>
<ul>
<li><a href="/about">About</a></li>
<li><a href="/services">Services</a></li>
<li><a href="/contact">Contact</a></li>
</ul>
</main>A step in a checkout may omit navigation and search. Do not add multiple ways there, but do give a clear way back to the cart.
<!-- Checkout step 3 with the full mega menu --><!-- Checkout step 3 -->
<a href="/cart">Back to cart</a>This criterion concerns sets of web pages. In native apps the same need is usually met by a navigation bar plus search, and the pattern is worth following as good practice.
import SwiftUI
struct CatalogScreen: View {
@State private var query = ""
var body: some View {
// Two ways to find content: the tab bar and search
TabView {
NavigationStack {
ProductList()
.searchable(text: $query, prompt: "Search products")
.navigationTitle("Products")
}
.tabItem { Label("Products", systemImage: "bag") }
HelpScreen()
.tabItem { Label("Help", systemImage: "questionmark.circle") }
}
}
}import androidx.compose.material3.*
import androidx.compose.runtime.*
@OptIn(ExperimentalMaterial3Api::class)
@Composable
fun CatalogScreen() {
var query by remember { mutableStateOf("") }
Scaffold(
// Way 1: bottom navigation
bottomBar = { NavigationBar { /* items: Products, Help */ } },
topBar = {
// Way 2: search
SearchBar(
query = query,
onQueryChange = { query = it },
onSearch = { /* run search */ },
active = false,
onActiveChange = {},
placeholder = { Text("Search products") }
) {}
}
) { padding -> ProductList(padding, query) }
}Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
