Understanding WCAG SC 2.4.5: Multiple Ways (AA)

Section 1: The Normative Requirement and Core Intent of SC 2.4.5

1.1 Analysis of the Normative Text (The "Letter of the Law")

Success Criterion (SC) 2.4.5 Multiple Ways is a Level AA conformance requirement under Guideline 2.4 Navigable, part of the "Operable" principle of the Web Content Accessibility Guidelines (WCAG). The full normative text of the criterion is:

"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. (Level AA)".

The term "normative" is defined by the W3C as "required for conformance". This text establishes a strict, testable requirement for any web property seeking Level AA conformance. This requirement is distinct from the supplementary "informative" materials, such as the "Understanding" and "Techniques" documents, which exist to explain and provide non-mandatory examples of how to meet this normative rule.

1.2 The Guiding Principle (The "Spirit of the Law"): User Choice and Cognitive Accommodation

The core intent of SC 2.4.5 is not simply to mandate a minimum of two links. The W3C's "Understanding" documents clarify that the fundamental goal is "to make it possible for users to locate content in a manner that best meets their needs". This criterion is a direct and explicit acknowledgment that "Not everyone can navigate content in the same way".

A single, rigid information architecture (IA)—such as a complex, multi-level hierarchical navigation menu—may be an effective tool for some users, but it can present a significant barrier for others. Individuals with cognitive limitations, for example, may find such hierarchical schemes "difficult to understand" or to mental-map.

Therefore, this success criterion mandates a form of information architecture redundancy. It requires that a site provide alternative models of its own structure, allowing a user to select the navigational paradigm that best aligns with their cognitive or browsing model. This requirement forces a shift in design philosophy, moving from a single "correct" way to find information to a more flexible and accommodating approach. It is a requirement for cognitive flexibility to be built into the site's foundational design. A 'search' function, for instance, offers a non-hierarchical, keyword-based model, while a 'site map' offers a flattened, complete-overview model. Providing these alternatives is a direct remedy for the cognitive overload that a single, complex hierarchy can induce.

1.3 Defining the Scope: What Constitutes a "Set of Web Pages"?

The SC's scope is explicitly constrained to locating a Web page "within a set of Web pages". This is a formally defined term. The W3C defines a "set of Web pages" as a "collection of Web pages that share a common purpose and that are created by the same author, group or organization".

This definition serves as the primary scoping mechanism. It means the criterion applies to an entire website (e.g., an e-commerce site) or a distinct, large-scale sub-section that functions as a cohesive whole (e.g., a "Help Center" or a "Developer Portal").

This requirement is not limited to large, complex sites. The W3C documentation specifies that "Even small sites should provide users some means of orientation". For a "three or four page site," a highly complex solution is not required. In this scenario, "it may be sufficient simply to provide links from and to the home page where the links on the home page can also serve as a site map". This specific solution for very small sites is formalized in W3C's "Sufficient Technique" G185: "Linking to all of the pages on the site from the home page".

This scoping definition also introduces a multi-level compliance challenge. The SC applies to the "set" (the entire site). However, as will be analyzed in Section 4, a separate technique, G64 (Providing a Table of Contents), applies to a "document" (e.g., a multi-page user guide) within that set. This implies that a large, complex website may need to satisfy SC 2.4.5 at multiple levels of granularity:

1. Site-Level (the "Set"): Using a technique like a G63 Site Map or G161 Search to navigate the entire site.
2. Document-Level (the "Document"): Using a G64 Table of Contents to navigate a complex, multi-page document published on that site.

Understanding this distinction between a "set of pages" and a "document" is fundamental to correctly auditing and implementing this success criterion on complex web properties.

Section 2: Beneficiary Analysis: The User-Centric Impact of Multiple Pathways

The requirement for multiple navigational pathways provides distinct, significant benefits to a wide range of users, including those with cognitive, visual, and motor disabilities, as well as enhancing the experience for all users.

2.1 Cognitive and Learning Disabilities

This group is a primary beneficiary of SC 2.4.5. Users who "struggle with complex site structures" or find a "hierarchical navigation scheme that may be difficult to understand" are given a direct alternative.

A typical hierarchical "fly-out" menu can be overwhelming, requiring users to hold a complex, branching structure in their working memory. A "table of contents or site map," by contrast, provides a static, two-dimensional "overview of the site", which can be less cognitively demanding to process.

Conversely, some users with cognitive limitations may "prefer to explore the site in a sequential manner", moving from one page to the next logical page. A technique like G125 (Providing links to navigate to related Web pages) directly supports this model. Other users may find a search feature easiest. The value of SC 2.4.5 is in providing this choice. It creates a necessary and beneficial tension between different navigational models. A typical hierarchical tree structure benefits users who are willing and able to learn the site's specific mental model. SC 2.4.5 forces the introduction of alternative models to accommodate users who cannot:

• A flat model (e.g., G63 Site Map) for a complete overview.
• A keyword model (e.g., G161 Search) for direct, non-sequential access.
• A contextual model (e.g., G125 Related Links) for sequential exploration.

This acknowledgment that a single, rigid IA is inherently inaccessible to a portion of the population is at the heart of this criterion.

2.2 Visual Impairments (Screen Reader and Magnifier Users)

The benefit for users with visual impairments is specific and crucial. As the W3C notes, "Users with visual impairments may find it easier to navigate to the correct part of the site by using a search, rather than scrolling through a large navigation bar using a screen magnifier or screen reader".

For a screen reader user, a large, deeply nested navigation menu is a significant linear obstacle. It represents a large block of dozens of links that must be audibly processed or skipped on every single page load. While SC 2.4.1 (Bypass Blocks) provides a mechanism to skip this "wall" of links, SC 2.4.5 provides a tool (like a search function) that allows the user to avoid engaging with the wall entirely. A user can navigate to the search bar—often placed prominently near the top of the page—and use it as their primary method of navigation, effectively bypassing the complex hierarchy that is inefficient for them to use.

Similarly, for a screen magnifier user, a large "mega-menu" that expands on hover can be extremely difficult to use, as it may cover a large portion of the screen, forcing the user to pan back and forth to understand their location within the menu structure. A static sitemap page or a search function provides a much more stable and predictable interface.

2.3 Keyboard and Assistive Technology Users (Motor Disabilities)

For users with motor disabilities who rely on keyboard-only navigation (e.g., using the Tab key) or other assistive technologies like switch devices, SC 2.4.5 helps "reduce frustration" and, critically, reduces the physical effort and fatigue of navigation.

If a site's primary navigation menu contains 50 links, and the user wishes to access the "Contact Us" link located in the footer, they may be forced to press the Tab key over 50 times on every single page to reach their target. This is a significant and fatiguing barrier. A search bar or a sitemap link, which can be reached in a few Tab presses (especially if placed near the start of the focus order or if "bypass blocks" are also implemented), provides a vital shortcut that dramatically reduces the cumulative physical effort required to interact with the site.

2.4 Universal Design Benefit (All Users)

Ultimately, offering multiple ways to navigate benefits all users by catering to diverse "browsing styles" and helping everyone "find information faster".

Information retrieval science identifies two primary modes of user behavior:

1. Known-Item Seeking: The user knows what they are looking for (e.g., "I need the-page-about-X").
2. Exploratory Browsing: The user is exploring the site's offerings (e.g., "I wonder what this site has?").

A well-implemented search function (Technique G161) perfectly serves the "seeking" user, while a hierarchical navigation menu and a G63 Site Map serve the "browsing" user. By providing mechanisms for both models, the site becomes more efficient and user-friendly for its entire audience, regardless of ability.

Section 3: Analysis of Sufficient Techniques (Part 1): Site-Wide Locators

The W3C provides a list of "Sufficient Techniques," which are non-mandatory methods that the WCAG Working Group has determined are "sufficient for meeting" the success criterion. For SC 2.4.5, a site must implement one or more of these techniques (or a different, unlisted technique that satisfies the SC's intent) in addition to its primary navigation mechanism.

The W3C lists G125, G64, G63, G161, G126, and G185 as sufficient. These techniques are not interchangeable; they have different scopes, technical implications, and maintenance costs. The table below provides a high-level comparison of these techniques.

---

Table 1: Comparative Analysis of Sufficient Techniques for SC 2.4.5

---

3.1 In-Depth Technical Analysis: G161 (Providing a search function)

This is one of the most common and effective techniques for satisfying SC 2.4.5 on medium to large websites. However, simply adding a search box is not sufficient. The implementation has several technical requirements.

Technical Requirement 1: The Form Must Be Accessible
The W3C documentation explicitly states, "The search form itself must be accessible, of course". This creates a dependency on other WCAG criteria. At a minimum, the search input field must have an accessible name (e.g., via <label>, aria-label, or aria-labelledby) to satisfy SC 3.3.2 (Labels or Instructions) and SC 4.1.2 (Name, Role, Value). The search "submit" button must also have an accessible name.
Technical Requirement 2: The Search Must Be Functional
A non-functional search box does not meet this technique. The W3C provides a test procedure:

1. Check that the Web page contains a search form or a link to a search page.
2. Type text "term" or "contains a list of links to pages containing the search term".

Technical Requirement 3: Optimization and Effectiveness
A search function that technically works but provides consistently poor, irrelevant results may fail to meet the intent of the SC, which is to help users find content. The W3C documentation provides a profound and often-overlooked note: "Techniques that are used to optimize search engine results for external searches also support internal search engines". This includes the use of "keywords, META tags, and an accessible navigation structure".
This implies that a truly effective G161 implementation is not just a front-end component but a back-end information science challenge. A simple database query (e.g., LIKE '%term%') is a weak implementation. A robust solution, as advised by guidelines from Google and Yahoo , would require a search engine that understands synonyms, handles common misspellings, and allows for content tagging and metadata to improve result relevancy.

Examples of G161 include an e-commerce site where users can search for product numbers or descriptions and a large Help Center with thousands of articles.

3.2 In-Depth Technical Analysis: G63 (Providing a site map)

This technique refers to a "Web page that provides links to different sections of the site". It is critical to distinguish this from an XML sitemap, which is a machine-readable file for search engine crawlers. G63 requires an HTML sitemap intended for human users.

Purpose and Implementation
The G63 sitemap "provides an overview of the entire site" and helps users "understand... how the content is organized". It serves as a powerful alternative to a "complex navigation bar". A well-designed sitemap consists of a "list or outline format of discernible text links" and should be built with "semantic HTML" (e.g., using nested lists to represent hierarchy). The WAI site map is cited as a positive example.
Technical Requirement 1: Linkage
The sitemap itself must be findable. The W3C states: "To make the site map available within the site, at a minimum every page that is listed in the site map contains a link to the site map". The accepted industry standard implementation that satisfies this is a single, site-wide link in the page footer.
Technical Requirement 2: Validity and Maintenance
This is the most critical and most frequently failed aspect of G63. A sitemap is a living document, not a static, "launch-day" asset. The W3C is explicit:
"A site map describes the contents and organization of a site. It is important that site maps be updated whenever the site is updated.".

A page is not a valid sitemap if it "contains links that are no longer valid" (i.e., 404 errors), "does not link to all the sections of a site," or "presents an organization that is different from the site's organization".

This "validity" requirement means that for any site that is not completely static (e.g., any site using a Content Management System - CMS), a manually created HTML sitemap will almost certainly fall out of compliance and become a failure of the technique. This has significant architectural implications: a compliant G63 sitemap must be dynamically generated by the CMS, automatically updating as pages are added, moved, or removed.

Section 4: Analysis of Sufficient Techniques (Part 2): Document and Contextual Locators

This group of techniques addresses navigation within a more specific scope: either within a single "document" or based on editorial context.

4.1 Critical Distinction: G63 (Sitemap) vs. G64 (Table of Contents)

This distinction is fundamental for correct compliance. Misunderstanding it is a common source of audit errors.

• G63 (Sitemap): Provides links to sections of the entire Web site. The W3C uses the analogy of a "library" containing many books.
• G64 (Table of Contents): Provides links to sections and subsections of the same document. The W3C uses the analogy of a single "book".

This distinction is nuanced by the fact that a G64 "document" is not necessarily a single Web page. The W3C clarifies that the sections of a document "could be located on the same Web page or spread across multiple Web pages." The key identifier is that "together, they make a complete idea".

For example, the WAI website as a whole (the "set of pages") has a G63 Site Map. The WCAG 2.0 specification (a "document" which is part of that site, but is a complete idea in itself) has a G64 Table of Contents.

This creates the "nested compliance" challenge. A large corporate site (a "set") can achieve site-wide 2.4.5 compliance with a G63 Sitemap and a G161 Search. However, if that site publishes a 50-page user guide, published as 50 separate HTML pages, that user guide is a "document" existing within the "set." For this document, a G64 Table of Contents (e.g., a persistent sidebar listing all 50 sections) is required to meet 2.4.5 for that document. The site-wide G63 sitemap does not satisfy the requirement for the document, and the document's G64 ToC does not satisfy the requirement for the entire site. Compliance must be evaluated at both the macro (site) and micro (document) levels.

4.2 In-Depth Technical Analysis: G64 (Providing a Table of Contents)

Purpose and Implementation (HTML)
The purpose of G64 is to give users an "overview of the document's contents and organization" and allow them "to go directly to a specific section". It is particularly useful for documents "intended to be read sequentially". In HTML, this is typically a hierarchical list of links at the start of the document or in a persistent navigation block.
Implementation (PDF)
The W3C documentation explicitly links this technique to PDF accessibility. Technique PDF2, "Creating bookmarks in PDF documents," is cited as an implementation of G64. This involves using the authoring tool (e.g., Microsoft Word, Adobe Acrobat Pro) to convert the document's heading structure (e.g., Heading 1, Heading 2) into a navigable "Bookmarks" pane within the PDF. For a PDF, the combination of a hyperlinked Table of Contents page and the PDF Bookmarks pane would satisfy SC 2.4.5.

4.3 In-Depth Technical Analysis: G125 (Providing links to navigate to related Web pages)

This technique is fundamentally different from the structural locators (G161, G63, G64). G125 is about contextual or relational navigation.

Function and Implementation
The function of G125 is to allow users, as they are "browsing the document," to "follow these links to find related information". This technique is not a single, centralized component; rather, it is a content and editorial strategy that is implemented within the main content of individual pages.
Common examples include:

• A "Related Articles" block at the end of a blog post.
• A "Related Products" or "Customers Also Bought" section on an e-commerce page.
• "See Also" sections in technical documentation.
• In-line links to definitions of terms used in a document.

G125 is the only technique that is fully integrated into the editorial content. While G161 (Search) and G63 (Sitemap) are "set it and forget it" technical components, G125 requires an active, ongoing editorial policy and content governance. It would be difficult to claim G125 as the only supplemental method of navigation for a large site, as an auditor would need to determine if all pages have sufficient related links to constitute a valid "way to locate" other pages. It is more realistically used as a powerful supplement to a primary structural solution like G161 or G63.

4.4 In-Depth Technical Analysis: G126 & G185 ("All Pages" Links)

These two techniques represent the simplest implementation, reserved for the smallest sites.

• G126: "Providing a list of links to all other Web pages".
• G185: "Linking to all of the pages on the site from the home page".

These are functionally identical for a very small site. As noted in Section 1.3, for a 3-4 page site, the main navigation on the home page is the list of all pages, and this is "sufficient" to meet the criterion. Attempting this on a 100-page site would be a usability and accessibility failure, as it would create a massive, unusable list of links, violating the intent of the SC even if it technically passed.

Section 5: The Critical Exception: Deconstructing "A Step in a Process"

SC 2.4.5 contains one, and only one, exception. This exception is critical for the functioning of modern web applications.

5.1 The Normative Text of the Exception

The requirement for multiple ways to locate a page does not apply "where the Web Page is the result of, or a step in, a process.".

5.2 W3C Definition of "Process"

To understand the exception, one must first understand the W3C's definition of a "process":

"series of user actions where each action is required in order to complete an activity".

The key phrase is "each action is required." This implies a forced, linear sequence where steps cannot be skipped.

5.3 Analysis of Canonical Examples

The W3C "Understanding" documents provide clear examples of what constitutes a "process":

• E-commerce Checkout: This is the most-cited example. A checkout flow is a "series of Web pages on a shopping site" requiring users to "select products, submit an order, provide shipping information and provide payment information". These pages—Shipping, Payment, Confirm Order—are sequential, required steps.
• Multi-Page Survey/Application: A linear survey, a multi-page job application, or an online test are all "processes". Step 3 cannot be completed before Step 2.
• Authentication and Registration: An example given is a page requiring a "Turing test (CAPTCHA)" before the registration form can be accessed. The CAPTCHA page is a required step in the registration process.
• Search Results Page: This is a subtle but important example of "the result of... a process". A page of search results is dynamically generated by the process of searching. There is no other way to locate that specific, transient page, so it is exempt.

5.4 The Rationale for the Exception

The exception exists for a critical reason: to "maintain the integrity of the process". It is a functional exception, not a content exception. It exists to protect the logic of a multi-step application.

Allowing users to locate and jump into the middle of a process would be detrimental, would break application logic, and would confuse the user. For example, if the "Payment" page of a checkout flow were listed in the sitemap, a user could jump directly to it. However, the application would have no shipping address or selected products in its session data, and the process would fail.

In this rare case, WCAG explicitly prioritizes application integrity over universal findability, because universal findability would render the application unusable.

This exception, however, creates a critical "boundary" problem for architects and auditors. One must precisely define when the "process" begins and ends. For example, the shopping cart page itself is generally not considered part of the exempt process. A user can (and should) be able to locate their cart from any page on the site (e.g., via a header icon). The "process" only begins when the user clicks "Proceed to Checkout."

A common failure is to over-apply this exception. For instance, the main "Login" page or "Forgot Password" page is not a step in a process; it is a gateway to a process. These pages must be findable (e.g., in the site header or sitemap). However, the "Password Reset Step 2" page, which requires a valid token from Step 1, is a step in a process and is exempt.

Section 6: Documented Failures, Advisory Techniques, and Non-Web Applications

6.1 Investigating Failures: The Curious Lack of Specific Documented Failures

The W3C's "Understanding" documents for many SCs include a list of common, documented "Failures" (e.g., "F8: Failure of Success Criterion 1.2.2...").

Significantly, the "Understanding" document for SC 2.4.5 states:

"Common Failures for SC 2.4.5. The following are common mistakes that are considered failures... (No failures currently documented).".

This is a highly revealing data point. The lack of specific, technical "F..." failures suggests that SC 2.4.5 is not a "bug-level" criterion. Many SCs are failed by a specific, component-level bug: a missing alt attribute (a failure of 1.1.1), a low-contrast color choice (a failure of 1.4.3), or an empty link (a failure of 2.4.4). These are often "cascading failures" from a single template error.

SC 2.4.5 is different. The lack of specific failures implies it is a "policy" or "architectural" criterion. A site fails 2.4.5 because of a strategic decision (or lack thereof) at the Information Architecture level. The only "failure" is providing only one mechanism to locate pages for a set of pages (that are not part of a process).

This makes remediation for 2.4.5 fundamentally different from most other criteria. A missing alt text can be fixed in a 5-minute bug ticket. A 2.4.5 failure cannot. To "fix" a 2.4.5 failure, an organization must architect, design, build, and populate an entire new site feature, such as a G63 sitemap or a G161 search engine. This makes SC 2.4.5 one of the more "expensive" and "foundational" criteria to remediate if it is ignored during the initial design and build.

6.2 Advisory Technique Analysis: H59 (Using the <link> Element)

The W3C also provides "Advisory" techniques, which are "not required for conformance" but "should be considered" as best practices. For SC 2.4.5, the primary advisory technique for HTML is H59: "Using the link element and navigation tools".

Technical Implementation (H59)
This technique involves using the <link> element within the <head> of an HTML document to provide semantic "metadata about the position of an HTML page within a set of Web pages".
This is accomplished using the rel attribute to define the relationship. Key rel values include:

• rel="next": Refers to the next document in a linear sequence.
• rel="prev": Refers to the previous document in a sequence.
• rel="contents": Refers to a document serving as a table of contents.
• rel="index": Refers to a document providing an index.
• rel="start": Refers to the first document in a collection.

Benefit and Context
This technique provides this relational information semantically to user agents (browsers) and assistive technologies. While most modern visual browsers no longer expose this information to the user (e.g., as a "Next" button in the browser chrome), assistive technologies can still read this metadata and present it to the user as a navigation option.
This makes H59 a "pure" accessibility technique: it provides information only to assistive technology, with no default visual component. While it is only "Advisory" for SC 2.4.5, it is a hallmark of high-quality, semantic-first development. Notably, H59 is considered a "Sufficient" technique for SC 2.4.8 (Location).

6.3 Applicability to Non-Web ICT and Documents

PDF Documents
The applicability of SC 2.4.5 extends beyond HTML. As analyzed in Section 4.2, the technique PDF2 ("Creating bookmarks in PDF documents") is explicitly listed as a method for satisfying G64 (Table of Contents). This confirms that a long, complex PDF "document" is subject to this criterion. To conform, a PDF would typically provide two ways to navigate: the hyperlinked Table of Contents (visible on a page) and the navigable Bookmarks pane (available in the PDF reader's user interface).
Non-Web Software
The landscape is different for non-web software (e.g., a desktop application). Guidance on applying WCAG to non-web technologies (known as WCAG2ICT) and standards like Section 508 note a specific exception. Non-web software is not required to conform to SC 2.4.5. This is a logical exception, as the "set of web pages" paradigm does not map cleanly to a native application's user interface, which has its own well-defined, platform-specific navigation conventions (e.g., menu bars, toolbars, and tabbed interfaces).

Section 7: Synthesis and Practical Implementation Models

7.1 Recommended Combinations (The "Two-Technique" Rule)

To conform, a site must provide "more than one way," which means the primary navigation (Way 1) must be supplemented by at least one other way (Way 2). The choice of Way 2 depends on the site's size and purpose.

• Model 1: The Standard Corporate/E-commerce Site (The "Go-To" Solution)
  • Way 1: Primary Hierarchical Navigation Menu.
  • Way 2: G161 (Providing a search function).
  • This is the most common, user-friendly, and expected combination for most modern websites. It serves both "browsing" and "seeking" user behaviors.
• Model 2: The Content-Heavy/Archive/Government Site
  • Way 1: Primary Hierarchical Navigation Menu.
  • Way 2: G63 (Providing a site map).
  • For a site with a vast, deeply-organized archive of content, a sitemap is often more useful than search for users who need to understand the full scope of the site's contents.
• Model 3: The Very Small Site (e.g., a brochure site)
  • Way 1: G185 (Linking all pages from the home page).
  • Way 2: G125 (Contextual related links on each page).
  • For a 3-4 page site, the home page navigation itself serves as a sitemap, and contextual links between pages (e.g., from "Services" to "About") provide the second method.

7.2 Integrating Other Navigational Aids (Best Practices vs. Compliance)

Several common navigation patterns are excellent for accessibility but must be correctly categorized in an audit.

• Breadcrumbs (Technique G65): This is a critical point of confusion. Breadcrumbs are a "Sufficient Technique" for SC 2.4.8 Location, not SC 2.4.5 Multiple Ways. The reason is that breadcrumbs only show the user one path (the hierarchical one they took) back to the home page. They do not offer an alternative way to locate a different page (e.g., to jump from one branch of the site to another). A sitemap (G63) lets a user jump from A -> B -> C to X -> Y -> Z. A breadcrumb only lets the user go from A -> B -> C back to B or A. This is a vital distinction. Breadcrumbs are an essential best practice but do not satisfy this criterion.
• A-Z Index: An A-Z index is a powerful mechanism, especially for sites with many defined terms, products, or articles (e.g., a glossary or encyclopedia). In WCAG terms, an A-Z index is a specific, highly-organized implementation of G63 (Sitemap) or G126 (List of links to all other Web pages).
• Footer Links: Repeating the most important links in the site footer is a common usability pattern. This provides a secondary, consistent navigation block. This location is the standard, best-practice location for the link to the G63 Sitemap, the G64 Table of Contents (for a multi-page document), or the "Contact" page.

7.3 Concluding Analysis: SC 2.4.5 as a Keystone of Navigable and Cognitive Accessibility

The analysis of Success Criterion 2.4.5 reveals that it is not a minor, component-level "bug" to be fixed, but a foundational, structural requirement that fundamentally shapes a user's experience and a site's architecture.

It is one of the most critical criteria addressing information architecture accessibility. It mandates that designers and architects move beyond a single, "correct" site hierarchy and embrace the fact that different users have different mental models, cognitive needs, and browsing strategies.

Compliance is not a simple checkbox. It is a commitment to providing redundant, user-centric, and cognitively flexible information pathways. Whether through a robust search engine, a well-maintained sitemap, or a clear table of contents, the goal is to empower all users by giving them a choice in how they find and conceptualize information.