WCAG 2.4.5 Multiple Ways — Testing Guide for Mobile & Web Apps

WCAG 2.4.5 Multiple Ways requires that users can locate a web page or screen by at least two different mechanisms. The intent is to give people choice in how they navigate, especially when one method

Understanding WCAG 2.4.5 Multiple Ways (Plain English)

WCAG 2.4.5 Multiple Ways requires that users can locate a web page or screen by at least two different mechanisms. The intent is to give people choice in how they navigate, especially when one method may be difficult or unavailable due to disability, context, or preference. For a web site, the two mechanisms commonly satisfy the rule are: (1) a set of navigation links (e.g., a global menu or breadcrumb trail) and (2) a search function or a site map. For a mobile app, the same principle applies: users should be able to reach a particular screen via more than one path, such as a bottom navigation bar and a deep link or a searchable list.

The success criterion is Level AA, meaning it is required for conformance under many accessibility laws, including the EU European Accessibility Act (EAA) and the Americans with Disabilities Act (ADA) as interpreted by the Department of Justice. Failure to provide multiple ways can block users who rely on assistive technology, have motor impairments that make precise tapping difficult, or simply prefer a different navigation style.

Who It Affects and Real User Impact

People who benefit from multiple ways include:

• Screen‑reader users who may find a linear list of links easier to traverse than a hidden hamburger menu.
• Users with motor impairments who struggle with small touch targets; a search bar with voice input can reduce the need for precise gestures.
• Cognitive‑disability users who benefit from redundancy; if they forget where a feature lives, a second route reduces frustration.
• Power users who prefer keyboard shortcuts or command‑palette style navigation.
• Elderly users who may not be familiar with gesture‑based navigation and rely on visible menus.

When only a single path exists, a failure can manifest as:

• Inability to reach a settings screen because the only entry point is a hidden gesture that TalkBack does not announce.
• Missing a promotional offer because the only way to view it is via a swipe‑up carousel that lacks a visible button.
• Abandoning a checkout flow because the “Edit cart” link is only reachable through a long‑press context menu that is not exposed to switch‑control users.

These scenarios translate directly into lost conversions, increased support calls, and potential legal risk under the EAA (which mandates WCAG 2.1 AA for public sector websites and mobile apps) and ADA Title III litigation trends.

Common Violations: Web Examples

Each of these examples demonstrates a single point of entry to a set of pages, violating the requirement for at least two distinct mechanisms.

Common Violations: Mobile Examples (Android/iOS)

Android

iOS

These mobile patterns illustrate how a single gesture‑ or UI‑dependent path can block users who cannot perform that gesture or who rely on assistive technology that does not expose it.

Manual Testing Approach

Testing WCAG 2.4.5 manually involves verifying that each screen or state provides at least two distinct ways to reach it. The process can be broken into three phases: discovery, verification, and documentation.

1. Discovery

• List all reachable screens: Use the app or site as a typical user would, noting every distinct screen (e.g., Home, Profile, Settings, Product Detail, Checkout Confirmation). For web, a sitemap generator (e.g., Screaming Frog) can help enumerate URLs. For mobile, tools like adb shell dumpsys activity or Xcode’s debug view hierarchy can list visible view controllers.
• Identify navigation mechanisms: For each screen, record the mechanisms that lead to it. Common mechanisms include:
• Global navigation (top nav, bottom nav, drawer, tab bar)
• Local controls (buttons, links, list items)
• Search (site‑wide or scoped)
• Breadcrumbs
• Site map or help page
• Deep links / URL schemes
• Voice commands or shortcuts
• Context menus (long‑press, right‑click)
• Keyboard shortcuts (e.g., Ctrl+K for command palette)

2. Verification

For each screen, attempt to reach it using at least two of the identified mechanisms while simulating different user profiles:

If a screen is reachable only via a single mechanism for any profile, flag it as a violation.

3. Documentation

Record findings in a table similar to the one below:

Manual testing is time‑consuming but essential for catching context‑specific issues (e.g., a navigation item that disappears after a certain state).

Automated Testing Tools and Techniques

Automated checks can catch many structural violations, especially those related to missing alternative navigation elements in the DOM or view hierarchy. However, automation cannot fully substitute for human judgment about usability; it should be used as a first line of defense.

Web Automation

Example: Custom axe rule for Multiple Ways

// multiple-ways.js
module.exports = {
  id: 'multiple-ways',
  description: 'Page must provide at least two distinct navigation mechanisms.',
  tags: ['wcag2aa', 'wcag245'],
  matcher: function (node) {
    return node.nodeType === Node.ELEMENT_NODE && node.matches('body');
  },
  evaluate: function (node, options) {
    const navs = Array.from(node.querySelectorAll('nav, [role="navigation"]'));
    const search = node.querySelector('input[type="search"]');
    const siteMapLink = Array.from(node.querySelectorAll('a')).find(a =>
      a.href.includes('sitemap') || a.textContent.toLowerCase().includes('site map')
    );
    const mechanisms = navs.length + (search ? 1 : 0) + (siteMapLink ? 1 : 0);
    return mechanisms >= 2 ? [] : [{
      message: 'Less than two navigation mechanisms found.',
      nodes: [{ target: [node] }],
      failureSummary: 'Provide at least two ways to reach content (e.g., nav + search or nav + sitemap).',
      id: 'multiple-ways'
    }];
  }
};

Register the rule with axe: axe.configure({ rules: [{ id: 'multiple-ways', enabled: true }] });.

Mobile Automation

Example: Espresso test for Multiple Ways

@Rule
public ActivityTestRule<MainActivity> activityRule =
        new ActivityTestRule<>(MainActivity.class);

@Test
public void settingsScreenHasMultipleWays() {
    // Way 1: via bottom navigation
    onView(withId(R.id.bottom_nav_settings)).perform(click());
    onView(withText("Settings")).check(matches(isDisplayed()));

    // Reset to home
    pressBackUnconditionally();

    // Way 2: via search
    onView(withId(R.id.search_view)).perform(click());
    onView(withId(R.id.search_src_text)).perform(typeText("settings"), closeSoftKeyboard());
    onView(withText("Settings")).check(matches(isDisplayed()));
}

If either path fails, the test fails, indicating a missing alternative route.

Limitations of Automation

• Automation can confirm the presence of navigation elements but cannot guarantee they are usable (e.g., a nav item may be present but hidden behind a modal that only appears after a gesture).
• It cannot assess cognitive load or the clarity of labels.
• Therefore, automated checks should be complemented with manual persona‑based testing and, where possible, autonomous exploration.

Fixing Violations: Code Examples (Web, Android, iOS)

Below are concrete remediation patterns for the most frequent violations identified earlier.

Web: Adding a Search Mechanism When Only a Menu Exists

Before

<header>
  <button id="hamburger" aria-label="Open menu">☰</button>
  <nav id="main-nav" style="display:none;">
    <ul>
      <li><a href="/home">Home</a></li>
      <li><a href="/products">Products</a></li>
      <li><a href="/about">About</a></li>
    </ul>
  </nav>
</header>

After

<header>
  <button id="hamburger" aria-label="Open menu">☰</button>
  <nav id="main-nav">
    <ul>
      <li><a href="/home">Home</a></li>
      <li><a href="/products">Products</a></li>
      <li><a href="/about">About</a></li>
    </ul>
  </nav>
  <!-- Search mechanism -->
  <form role="search" aria-label="Site search">
    <label for="site-search" class="visually-hidden">Search the site</label>
    <input type="search" id="site-search" placeholder="Search…" aria-controls="search-results">
    <button type="submit">Search</button>
  </form>
</header>

• The hamburger button is now focusable and the menu is displayed by default (or toggled via ARIA‑expanded).
• A search form provides a second mechanism.
• Use visually-hidden class to hide the label visually but keep it accessible to screen readers.

Web: Ensuring Breadcrumbs Appear on All Pages

Before (only on homepage)

<!-- Only on / -->
<nav aria-label="breadcrumb">
  <ol>
    <li><a href="/">Home</a></li>
    <li aria-current="page">Home</li>
  </ol>
</nav>

After (added to a template partial)

<!-- In base layout -->
<nav aria-label="breadcrumb">
  <ol>
    <li><a href="/">Home</a></li>
    {{#if currentCrumb}}
    <li><a href="{{currentCrumb.url}}">{{currentCrumb.label}}</li>
    {{/if}}
    <li aria-current="page">{{pageTitle}}</li>
  </ol>
</nav>

• The breadcrumb is rendered on every layout, providing a second navigational cue alongside the global menu.

Android: Providing an Alternative to Edge‑Swipe Drawer

Before (drawer only opens by swipe)

<androidx.drawerlayout.widget.DrawerLayout
    android:id="@+id/drawer_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent">
    <!-- content -->
</androidx.drawerlayout.widget.DrawerLayout>

After (add toolbar hamburger)

<androidx.drawerlayout.widget.DrawerLayout
    android:id="@+id/drawer_layout"
    android:layout_width="match_parent"
    android:layout_height="match_parent">

    <androidx.coordinatorlayout.widget.CoordinatorLayout
        android:layout_width="match_parent"
        android:layout_height="match_parent">

        <com.google.android.material.appbar.MaterialToolbar
            android:id="@+id/toolbar"
            android:layout_width="match_parent"
            android:layout_height="wrap_content"
            app:navigationIcon="@drawable/ic_menu"
            app:title="MyApp" />

        <!-- main content -->
    </androidx.coordinatorlayout.widget.CoordinatorLayout>

    <com.google.android.material.navigation.NavigationView
        android:id="@+id/nav_view"
        android:layout_width="wrap_content"
        android:layout_height="match_parent"
        android:layout_gravity="start"
        app:menu="@menu/drawer_menu"/>
</androidx.drawerlayout.widget.DrawerLayout>

In the Activity:

Toolbar toolbar = findViewById(R.id.toolbar);
DrawerLayout drawer = findViewById(R.id.drawer_layout);
ActionBarDrawerToggle toggle = new ActionBarDrawerToggle(
        this, drawer, toolbar, R.string.navigation_drawer_open,
        R.string.navigation_drawer_close);
drawer.addDrawerListener(toggle);
toggle.syncState();

• The toolbar icon provides a second, tap‑based mechanism that is announced by TalkBack as “Open navigation drawer”.
• Ensure the icon has a content description (provided by MaterialToolbar) and sufficient touch target size (≥48 dp).

Android: Adding a Search Action to the Toolbar

Before (no search)

<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item
        android:id="@+id/action_refresh"
        android:title="Refresh"
        android:orderInCategory="100"
        android:showAsAction="ifRoom"/>
</menu>

After (add search)

<menu xmlns:android="http://schemas.android.com/apk/res/android">
    <item
        android:id="@+id/action_search"
        android:title="Search"
        android:icon="@drawable/ic_search"
        android:showAsAction="ifRoom|collapseActionView"
        android:actionViewClass="androidx.appcompat.widget.SearchView"/>
    <item
        android:id="@+id/action_refresh"
        android:title="Refresh"
        android:orderInCategory="100"
        android:showAsAction="ifRoom"/>
</menu>

In the Activity:

@Override
public boolean onCreateOptionsMenu(Menu menu) {
    getMenuInflater().inflate(R.menu.main, menu);
    MenuItem searchItem = menu.findItem(R.id.action_search);
    SearchView searchView = (SearchView) searchItem.getActionView();
    searchView.setOnQueryTextListener(new SearchView.OnQueryTextListener() {
        @Override
        public boolean onQueryTextSubmit(String query) {
            // handle search
            return false;
        }
        @Override
        public boolean onQueryTextChange(String newText) {
            // filter list
            return false;
        }
    });
    return true;
}

• The search view is announced as “Search button, double tap to edit” and provides a keyboard‑friendly mechanism.

iOS: Ensuring Tab Bar Persists After Onboarding

Before (tab bar hidden permanently)

if !UserDefaults.standard.bool(forKey: "onboarded") {
    showOnboarding()
    tabBarController?.tabBar.isHidden = true
}

After (tab bar always visible; onboarding presented as a modal)

if !UserDefaults.standard.bool(forKey: "onboarded") {
    let onboarding = OnboardingViewController()
    onboarding.modalPresentationStyle = .fullScreen
    present(onboarding, animated: true, completion: nil)
}
// tabBar remains visible

• Users who skip onboarding still see the tab bar, giving them a second way to navigate (tab bar + any deep link or search).

iOS: Adding a Search Bar to Navigation Controller

Before (no search)

navigationItem.title = "Products"

After (add search controller)

let searchController = UISearchController(searchResultsController: nil)
searchController.obscuresBackgroundDuringPresentation = false
searchController.searchBar.placeholder = "Search products"
navigationItem.searchController = searchController
definesPresentationContext = true

• The search bar is announced by VoiceOver as “Search field, double tap to edit”.
• It provides an alternative to scrolling through a long list.

General Guidance for Code Fixes

1. Use semantic elements: <nav>, <header>, <footer>, <main>, <aside> on web; Toolbar, BottomNavigationView, TabBar on mobile.
2. Label everything: Provide aria-label or contentDescription for icons; ensure visible text labels accompany icons where possible.
3. Maintain sufficient touch target size: 48 dp (Android) or 44 pt (iOS) minimum.
4. Avoid relying solely on gestures: Always expose a button or control that duplicates the gesture’s function.
5. Test with real assistive tech: TalkBack, VoiceOver, Switch Control, keyboard-only navigation, and voice commands.

Autonomous Persona‑Driven Exploration (SUSA) and How It Checks WCAG 2.4.5

SUSA (SUSATest) is an autonomous QA platform that explores an app or web property without pre‑written scripts. It builds a behavioral model of the application by exercising a range of user personas—each with distinct interaction patterns, abilities, and goals. When evaluating WCAG 2.4.5 Multiple Ways, SUSA’s persona‑driven approach adds a layer of validation that static rules and manual spot checks can miss.

How SUSA Models Personas Relevant to 2.4.5

During a test run, SUSA logs each successful navigation to a target screen and records the mechanism used (e.g., “bottom‑nav tap”, “search query”, “voice command ‘open settings’”, “deep link myapp://profile”). After the exploration phase, it computes, for each screen, the count of distinct mechanisms observed across all personas. If any screen has fewer than two distinct mechanisms, SUSA raises a WCAG 2.4.5 violation with evidence (screenshots, logs, and the persona that failed to find an alternative).

Advantages Over Pure Automation

• Context‑sensitive: SUSA notices when a navigation item is present but obscured by a modal that only appears after a specific user action (e.g., a promo overlay). The “Impatient” persona may dismiss the overlay quickly, while the “Elderly” persona may get stuck, revealing a conditional block.
• Dynamic state coverage: By simulating personas that interact with forms, error dialogs, and permission prompts, SUSA can verify that navigation remains available in error states—a scenario often missed by static checks.
• Learning across sessions: The platform remembers which screens were reached via which mechanisms. In subsequent runs, it prioritizes unexplored combinations, gradually building a comprehensive map of redundant paths.
• Integration with CI: The CLI susatest-agent can be invoked as a step in a pipeline, uploading an APK or providing a URL, and returning a JSON report that includes a wcag245 section with pass/fail status and detailed logs.

Example CLI Invocation

# Install the agent (once)
pip install susatest-agent

# Run against a local Android emulator build
susatest-agent run \
    --apk ./app-release.apk \
    --device emulator-5554 \
    --personas curious,impatient,elderly,accessibility \
    --output ./report.json

The resulting report.json contains:

{
  "wcag245": {
    "passed": false,
    "violations": [
      {
        "screen": "Settings",
        "expectedMechanisms": 2,
        "observedMechanisms": 1,
        "mechanismsSeen": ["bottom_nav"],
        "missing": ["search"],
        "evidence": {
          "screenshot": "screenshots/settings_missing_search.png",
          "logs": [
            {"persona":"elderly","action":"swipe_up","result":"no_search_found"},
            {"persona":"accessibility","action":"voice_command_search","result":"not_recognized"}
          ]
        }
      }
    ]
  }
}

Teams can fail the build if passed is false, ensuring that any regression that removes a secondary navigation path is caught early.

Test Matrix: Combining Manual, Automated, Autonomous

The table illustrates that no single method is sufficient alone; combining them yields the highest confidence that WCAG 2.4.5 is satisfied across all user contexts.

Checklist for Developers and QA

Use this checklist before marking a feature as “Done”. Each item should be verified for both web and mobile implementations.