Multiple ways to find pages and the ADA

One door is not enough

A resident looking for "bulky waste pickup" might browse the Services menu, type into search, or scan an A to Z list. Someone with a cognitive disability may find menus hard to predict and prefer search. A person using a screen reader may find a sitemap faster than a deep menu. Offering several routes lets people use the one that fits.

Success Criterion 2.4.5 says 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. A checkout confirmation or a page of search results can only be reached by completing the earlier step, so it is exempt.

A "set of web pages" is a group of pages with a shared purpose from one author or organization, and different language versions count as separate sets. The usual approach is to combine two or more techniques from W3C's list: links to related pages (G125), a table of contents, a site map, a search function, a list of links to all pages, or links from the home page to all pages.

Sites that offer a single route

• County sites that rely on a large menu and have no search.
• Department microsites whose pages are only reachable from a parent page.
• Library and park pages with search but no list of services or locations.
• Apps with a tab bar and no way to search for a function.

Agencies usually have the pieces already; they are just not offered on every page.

An A to Z index

An alphabetical service list is a second route that works well for residents who know what they need but not which department handles it.

<nav aria-label="Main">
  <a href="/services">Services</a>
  <a href="/departments">Departments</a>
</nav>
<!-- no other route to specific services -->

<nav aria-label="Main">
  <a href="/services">Services</a>
  <a href="/departments">Departments</a>
  <a href="/services/a-z">Services A to Z</a>
</nav>

<!-- /services/a-z -->
<h1>Services A to Z</h1>
<nav aria-label="Jump to letter">
  <a href="#b">B</a> <a href="#p">P</a> <a href="#r">R</a>
</nav>
<h2 id="b">B</h2>
<ul><li><a href="/services/building-permits">Building permits</a></li></ul>

Breadcrumbs and related links

Links from related pages, such as a trail back through the hierarchy, are another route.

<h1>Special event permit</h1>
<p>…</p>

<nav aria-label="Breadcrumb">
  <ol>
    <li><a href="/">Home</a></li>
    <li><a href="/departments/parks">Parks and Recreation</a></li>
    <li aria-current="page">Special event permit</li>
  </ol>
</nav>
<h1>Special event permit</h1>
<aside aria-labelledby="rel">
  <h2 id="rel">Related services</h2>
  <ul><li><a href="/services/park-reservations">Park reservations</a></li></ul>
</aside>

Search that fits the content

Search is the most common second route. A scoped search suits sites with large document collections such as council records.

<input type="text" placeholder="Search">

<form role="search" action="/search">
  <label for="q">Search the site</label>
  <input id="q" type="search" name="q">
  <label for="scope">Search in</label>
  <select id="scope" name="scope">
    <option value="all">Entire site</option>
    <option value="docs">Council documents</option>
    <option value="services">Services</option>
  </select>
  <button type="submit">Search</button>
</form>

Apps with many destinations

WCAG 2.4.5 is written for sets of web pages, so for native apps this is a usability suggestion rather than a requirement. An app with many screens still benefits from search in addition to its tab bar. SwiftUI:

NavigationStack {
    ServiceList()
}

NavigationStack {
    ServiceList()
        .searchable(text: $query, prompt: "Search services")
}

Jetpack Compose:

Scaffold(bottomBar = { ServiceTabs() }) { ServiceList() }

Scaffold(
    topBar = {
        OutlinedTextField(
            value = query, onValueChange = { query = it },
            label = { Text("Search services") },
            singleLine = true,
            keyboardOptions = KeyboardOptions(imeAction = ImeAction.Search),
            keyboardActions = KeyboardActions(onSearch = { runSearch(query) })
        )
    },
    bottomBar = { ServiceTabs() }
) { ServiceList() }

Testing it

1. Pick five pages deep in the site. For each, list every way to reach it: menu, search, A to Z, related links, home page links.
2. Check that at least two routes exist for each page. As good practice, they should be offered from every page, not only the home page.
3. Mark pages that are steps in a process, such as an application step or a results page. These are exempt.
4. Check each language version separately.

A crawler can show orphan pages that no link points to, which is a quick way to spot pages with a single route or none.

Mistakes and a ship-it list

• Offering search on the home page only (not a failure by itself, but offering it on every page is better practice).
• Counting a footer link to the home page as a second route.
• Counting two menus that reach the same pages in the same way as separate routes.
• Forgetting the exemption applies to process steps, not to ordinary content.

Ship it when every page that is not a step in a process can be reached by at least two different means, such as navigation plus search or an index.

See common barriers for the barriers DOJ's guidance lists.

Sources

• Understanding SC 2.4.5: Multiple Ways (W3C), opens in a new tab
• 28 CFR Part 35, Subpart H: Accessibility of Web Information and Services (eCFR), opens in a new tab

Standard version: WCAG 2.1 (W3C Recommendation, 5 June 2018), as named in the Title II web rule. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official ADA statute and regulations, and ask a lawyer how they apply to you.