WCAG 2.4.5: Multiple Ways

What This Rule Means

WCAG 2.4.5 — Multiple Ways is a Level AA success criterion under the Operable principle. It requires that any web page which is part of a larger set of web pages must be reachable through at least two distinct navigation mechanisms. In other words, a user should never be forced to rely on a single route to find a page.

Common navigation mechanisms that satisfy this criterion include: a site-wide search function, a sitemap (either as a standalone page or an inline structure), a table of contents, a consistent navigation menu or sidebar, breadcrumb trails, and links between related pages. Any two of these — or other equivalent mechanisms — used together satisfy the requirement.

The criterion applies specifically to sets of web pages. A standalone web page that does not belong to a larger site or application is exempt. Additionally, pages that are the result of or a step in a process — such as a checkout confirmation page, a form submission success screen, or a wizard step — are also explicitly exempt. This is because such pages are inherently sequential and it would be inappropriate or harmful to allow direct access to them out of order.

A pass requires that at least two independent navigation mechanisms are present, functional, and accessible throughout the site. A fail occurs when only one mechanism exists — for example, a site that provides only a top navigation menu with no search, no sitemap, and no other navigational aid. It also fails if the secondary mechanism is non-functional or inaccessible (e.g., a search box that returns no results, or a sitemap that is hidden from assistive technologies).

Importantly, this criterion does not mandate any specific combination of mechanisms. The flexibility is intentional: different users have fundamentally different strategies for finding content, and the standard acknowledges this diversity by requiring redundancy rather than prescribing a particular solution.

Why It Matters

Navigation is the foundation of any web experience, and barriers to navigation disproportionately affect people with disabilities. When only one navigation path exists, users who cannot use that path are effectively locked out of content.

For users with motor impairments — including those who use switch access, eye-tracking devices, voice control software, or keyboard-only navigation — complex hierarchical menus can be exhausting or impossible to traverse efficiently. A site search allows them to jump directly to content without navigating through multiple levels of menus. Conversely, users with certain cognitive or memory impairments may find open-ended search fields confusing or difficult to use effectively; for them, a clearly structured sitemap or browsable category tree is far more useful.

For blind users relying on screen readers, a dense navigation menu can become a repetitive obstacle on every page visit, even with skip links. A sitemap or search shortcut reduces that cognitive and physical load significantly. For users with low vision who use screen magnification, broad navigation menus may only be partially visible at high zoom levels, making a text-based search or sitemap a critical fallback.

For users with cognitive disabilities such as dyslexia or attention disorders, the ability to search using approximate or partial terms — rather than needing to remember or recognize the exact menu hierarchy — can make the difference between finding content independently and giving up entirely.

A concrete real-world scenario: imagine a user with rheumatoid arthritis visiting a Turkish e-commerce platform using keyboard-only navigation. The site's mega-menu requires precise mouse hover interactions to reveal subcategories, and the keyboard focus behavior is unreliable. If the site also provides a search bar and a sitemap, that user can still locate the product page they need. Without those alternatives, the site is effectively unusable for them — and that represents a lost customer and a potential legal liability.

Beyond accessibility, multiple navigation mechanisms offer measurable SEO and usability benefits. Sitemaps improve crawlability by search engine bots. Site search functionality increases user engagement and reduces bounce rates. Breadcrumb trails improve click-through rates in search engine result pages when implemented with structured data. These benefits mean that satisfying 2.4.5 is not just a compliance exercise — it is sound web design practice.

Related Axe-core Rules

WCAG 2.4.5 requires manual testing because no automated tool can reliably determine whether a site provides sufficient navigational variety. Automated scanners can verify whether specific elements exist and are syntactically correct, but they cannot evaluate the site-wide navigational architecture or determine whether a given combination of mechanisms is genuinely adequate. The following considerations guide manual evaluation:

• Presence of a site search (manual check): Automated tools cannot confirm whether a search input is functional, returns meaningful results, or is accessible across the entire site. A tester must manually verify that a search mechanism exists, is reachable via keyboard, and produces relevant results for representative queries.
• Presence of a sitemap or alternative navigation mechanism (manual check): Tools cannot determine whether a sitemap page exists, whether it is linked from all pages, or whether it comprehensively covers site content. A human reviewer must confirm that at least one additional mechanism beyond the primary navigation is available and accessible.
• Consistency of navigation (relates to 2.4.3 and 3.2.3, manual check): Automated tools may flag inconsistent component ordering across pages, but cannot judge whether the overall navigation strategy remains coherent and sufficient for users with disabilities. Manual review across multiple representative page types is required.
• Accessibility of secondary mechanisms (manual check): Even if a sitemap or search exists, an automated scan may not catch cases where those mechanisms are keyboard-inaccessible, have poor screen reader labeling, or are visually hidden in a way that affects usability. Manual keyboard and screen reader testing must confirm each mechanism works end-to-end.

How to Test

1. Automated scan — establish a baseline: Run axe DevTools or Lighthouse against representative pages of the site. While neither tool directly flags 2.4.5 violations, use the audit to identify any navigation components (menus, search inputs, breadcrumbs) with underlying accessibility issues such as missing labels, improper ARIA roles, or focus management problems. Fix these first, as a broken navigation mechanism cannot count as a valid "way" under 2.4.5.
2. Catalog navigation mechanisms: Manually review the site and list every distinct mechanism a user could use to reach a given page: top navigation menus, footer links, site search, sitemap pages, breadcrumbs, related-content links, category indexes, and so on. Confirm that at least two of these mechanisms are present, functional, and available on every page that is not part of a sequential process.
3. Keyboard-only navigation test: Using only the Tab, Enter, Arrow keys, and Escape key (no mouse), attempt to reach a specific non-home page through two different mechanisms. For example, use the search bar to find a product page, then use the sitemap or navigation menu to reach the same page. Confirm both paths are fully operable without a mouse.
4. Screen reader test with NVDA + Firefox: Open NVDA, launch Firefox, and navigate to the home page. Use NVDA's browse mode (F6 for landmarks, H for headings) to locate the search landmark and any sitemap or navigation links. Confirm that both mechanisms are announced correctly, that form fields have accessible labels, and that results or destination pages load and are readable.
5. Screen reader test with VoiceOver + Safari (macOS/iOS): Activate VoiceOver (Cmd+F5) and use the Rotor (VO+U) to inspect the page's form controls and links. Confirm that the search field is listed and labeled, and that navigation links leading to a sitemap or alternative index are present and operable.
6. Screen reader test with JAWS + Chrome: Use JAWS navigation keystrokes (F to jump to forms, Insert+F7 for links list) to verify that the search input and any sitemap links are discoverable and usable from both the keyboard and the virtual cursor.
7. Sequential process exemption check: Identify any pages that are steps in a process (checkout, multi-step forms, login flows). Confirm that these pages do not need to satisfy the multiple-ways requirement. Document this in your accessibility audit to avoid false failures.
8. Functional search result verification: Perform several representative searches (product names, article titles, support topics). Confirm that results appear, are relevant, and that the results page is accessible and navigable by keyboard and screen reader.

How to Fix

Missing site search — Incorrect

<!-- Site only has a navigation menu; no search or sitemap provided -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>
<!-- No search, no sitemap link, no other navigation mechanism -->

Missing site search — Correct

<!-- Navigation menu retained, and a site search is added as a second mechanism -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/urunler'>Ürünler</a></li>
    <li><a href='/hakkimizda'>Hakkımızda</a></li>
    <li><a href='/iletisim'>İletişim</a></li>
  </ul>
</nav>

<!-- Second navigation mechanism: accessible site search -->
<form role='search' action='/arama' method='get'>
  <label for='site-search'>Sitede Ara</label>
  <input
    type='search'
    id='site-search'
    name='q'
    placeholder='Ürün veya konu arayın...'
    aria-label='Site genelinde arama'
  />
  <button type='submit'>Ara</button>
</form>

Inaccessible sitemap — Incorrect

<!-- Sitemap link is present but visually hidden and unreachable by keyboard -->
<footer>
  <a href='/site-haritasi' style='display:none;'>Site Haritası</a>
</footer>
<!-- display:none removes the element from both visual display AND
     the accessibility tree, so screen reader users cannot reach it.
     This sitemap cannot count as a valid second navigation mechanism. -->

Inaccessible sitemap — Correct

<!-- Sitemap link is visible and accessible to all users -->
<footer>
  <nav aria-label='Footer navigation'>
    <ul>
      <li><a href='/site-haritasi'>Site Haritası</a></li>
      <li><a href='/gizlilik'>Gizlilik Politikası</a></li>
      <li><a href='/iletisim'>İletişim</a></li>
    </ul>
  </nav>
</footer>
<!-- The sitemap page itself should list all major sections and pages
     of the site using <nav>, <ul>, and <a> elements. -->

Search form with no accessible label — Incorrect

<!-- Search input has no label; screen readers announce only 'edit text' -->
<form action='/search'>
  <input type='text' name='q' placeholder='Search...' />
  <button type='submit'><img src='search-icon.png' /></button>
</form>

Search form with no accessible label — Correct

<!-- role='search' identifies the landmark; label associates text with input;
     submit button has an accessible name via aria-label -->
<form role='search' action='/arama' method='get'>
  <label for='global-search'>Arama</label>
  <input
    type='search'
    id='global-search'
    name='q'
    autocomplete='off'
  />
  <button type='submit' aria-label='Aramayı başlat'>
    <img src='search-icon.png' alt='' aria-hidden='true' />
  </button>
</form>

Common Mistakes

• Counting an XML sitemap as a user-facing navigation mechanism: An XML sitemap submitted to search engines (e.g., /sitemap.xml) is a machine-readable file and cannot be used by ordinary visitors. Only an HTML sitemap page, browsable by humans, counts as a valid second navigation mechanism.
• Providing a search form that is purely decorative or broken: A search input that always returns empty results, errors on submission, or redirects to a 404 page does not satisfy 2.4.5. The mechanism must be genuinely functional for the criterion to pass.
• Hiding the sitemap link behind JavaScript that fails or is disabled: If the only link to a sitemap is inside a dynamically injected modal or a JavaScript-dependent dropdown that fails in certain environments, users who cannot execute that JavaScript (including some assistive technology configurations) lose access to that navigation mechanism.
• Applying display:none or visibility:hidden to a navigation mechanism on mobile viewports: Completely hiding a search bar or sitemap link in the mobile layout removes that mechanism for mobile users entirely, which is a fail — even if the desktop layout passes. Collapsing the mechanism behind an accessible toggle button is acceptable; removing it from the DOM or accessibility tree is not.
• Treating breadcrumbs as a standalone second mechanism without any additional support: Breadcrumbs only show the path to the current page and are not independently sufficient to help a user discover and navigate to arbitrary pages on a site. They can supplement other mechanisms but typically cannot serve as one of the two required mechanisms on their own.
• Exempting pages from the requirement incorrectly: The sequential-process exemption applies only to pages that are literally steps within a process (e.g., step 2 of 4 in a checkout). Category pages, product detail pages, and blog posts are not exempt, even if the user arrived there through a funnel.
• Using a search input with type='text' instead of type='search' and omitting role='search' on the form: While not a direct 2.4.5 violation, this means screen reader users browsing landmarks cannot find the search region. The mechanism technically exists but is practically harder to discover, undermining the intent of the criterion.
• Providing two mechanisms that are effectively identical: A top navigation menu and a footer navigation menu containing exactly the same links in exactly the same structure do not constitute two meaningfully different navigation mechanisms. The intent is that users with different needs can find alternative strategies — not that the same strategy appears twice on the page.
• Excluding certain page types from the navigation system: Some CMS configurations place blog posts, legal pages, or user-account pages outside the main site map or search index. If users cannot find these pages through at least two mechanisms, those pages fail 2.4.5 regardless of how well the rest of the site is structured.
• Failing to test the mechanisms with assistive technology: Because 2.4.5 requires manual testing, teams that rely solely on automated tools will miss failures caused by keyboard traps in search forms, unlabeled inputs, or sitemaps that are present in the DOM but unreachable via screen reader landmark navigation.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular No. 2025/10, published in the Official Gazette (Resmî Gazete) No. 32933 on June 21, 2025, establishes binding web accessibility obligations for a wide range of public and private sector entities. The Circular mandates conformance with internationally recognized accessibility standards, aligning Turkish legal requirements with WCAG 2.1 and WCAG 2.2 Level AA as the baseline expectation.

WCAG 2.4.5 — Multiple Ways is a Level AA criterion, which means it falls squarely within the conformance level required by the Circular. Entities subject to the regulation must ensure that all web pages belonging to a set provide at least two navigation mechanisms, as described in this criterion. Failure to satisfy this requirement is a direct non-conformance with the regulatory mandate.

The entities covered by Presidential Circular 2025/10 include: public institutions and government bodies at all levels; banks and financial institutions; hospitals and healthcare providers; electronic commerce platforms; telecommunications operators with 200,000 or more subscribers; travel agencies; private transport companies; and private schools operating under authorization from the Ministry of National Education (Millî Eğitim Bakanlığı, MEB). Each of these entity types is expected to maintain accessible, multi-path navigation across their web properties.

In addition to the mandatory conformance requirements, the Ministry of Family and Social Services (Aile ve Sosyal Hizmetler Bakanlığı) issues the Erişilebilirlik Logosu (Accessibility Logo) to organizations that demonstrate strong accessibility practices. Earning this logo requires full Level AA conformance, including compliance with 2.4.5. For businesses operating in Turkey's competitive digital market — particularly e-commerce platforms, banks, and healthcare providers — the Accessibility Logo serves both as a trust signal to users with disabilities and as evidence of regulatory good faith.

Practically speaking, Turkish websites serving diverse user populations benefit significantly from implementing multiple navigation mechanisms. Turkey has a large population of older internet users and users in regions with lower digital literacy, both of whom benefit from the redundancy that 2.4.5 mandates. A site search with Turkish language support (including correct handling of Turkish-specific characters such as ı, İ, ş, ğ, ü, ö, ç) combined with a clearly structured HTML sitemap represents an accessible, regulation-compliant implementation that serves this audience well. Organizations seeking to obtain or maintain the Erişilebilirlik Logosu should treat 2.4.5 compliance not as an optional enhancement but as a foundational requirement of their accessibility program.