WCAG 2.4.8: Location

What This Rule Means

WCAG 2.4.8 Location is a Level AAA criterion under the Operable principle. It states: "Information about the user's location within a set of Web pages is available." In practical terms, this means your website must provide clear, persistent signals that tell users exactly where they are within the broader structure of the site at any given moment.

This criterion applies whenever a website consists of multiple pages organized into a meaningful hierarchy or sequence — for example, an e-commerce site with categories, subcategories, and product pages, or a government portal with departments and sub-sections. If a user lands on a page, they should be able to answer the question "Where am I in this site?" without having to guess or rely solely on memory.

Acceptable techniques for satisfying this criterion include, but are not limited to:

• Breadcrumb trails — a navigational aid that shows the path from the site's home page to the current page (e.g., Home > Products > Laptops > 15-inch Models).
• Site maps — a dedicated page or panel that displays the overall structure of the site and highlights or marks the current location.
• Highlighted or visually distinct navigation links — navigation menus that clearly mark the active section or page, often supplemented with an aria-current attribute for assistive technology users.
• Numbered steps in a multi-step process — indicators such as "Step 2 of 5" in a checkout or form wizard that communicate sequential position.

A page passes this criterion if at least one reliable mechanism is available that informs the user of their current location within the site's structure. A page fails if no such mechanism exists — for example, if the navigation bar has no visual or programmatic indication of the current page, there is no breadcrumb, and no step indicator is shown.

It is important to note that WCAG 2.4.8 does not mandate a specific technique; it requires that some effective location indicator be present. However, for the indicator to be truly accessible, it must also be perceivable by assistive technologies such as screen readers, not only visually apparent to sighted users. This means that purely visual indicators (such as a bold link with no accessible label change) may be insufficient on their own if they are not programmatically exposed.

There are no official exceptions carved out by WCAG for this criterion beyond the general understanding that it applies to sets of related pages. A single standalone web page that is not part of a larger set would not need to satisfy this criterion, as there is no "location within a set" to communicate.

Why It Matters

Knowing where you are within a digital environment is a basic orientation need that most users take for granted — until the cues are absent. WCAG 2.4.8 addresses a real and pervasive barrier experienced by several distinct groups of users.

Users with cognitive disabilities are among those most significantly affected. Conditions such as attention deficit disorder, memory impairments, and acquired brain injuries can make it difficult to track one's path through a complex site. Without a breadcrumb or similar signal, a user may become disoriented, unsure how to return to a parent category, or unable to understand how the current page relates to content they have already seen. According to the World Health Organization, over one billion people worldwide live with some form of disability, and cognitive impairments represent a significant and often underserved portion of that population.

Screen reader users — who are typically blind or have low vision — rely heavily on programmatic structure to understand page context. A sighted user can glance at a highlighted navigation link or a bolded breadcrumb item to orient themselves instantly. A screen reader user, by contrast, must interpret the page through sequential audio output. Without an aria-current="page" attribute on the active navigation link or a properly structured breadcrumb with accessible labels, they receive no equivalent orientation signal and may need to navigate extensively just to determine where they are.

Users with motor impairments who navigate via keyboard, switch access, or eye-tracking devices benefit from location indicators because they reduce the need for redundant, effortful navigation. If a user already knows they are in the "Support" section of a corporate site, they do not need to re-scan the entire navigation structure each time they load a new page.

Consider a concrete scenario: a user with early-stage dementia is browsing a Turkish bank's online portal to find information about mortgage rates. They click through several pages and become unsure whether they are still in the personal banking section or have wandered into the business banking area. Without a breadcrumb trail or a highlighted navigation item clearly marking their current section, they may close the browser in frustration or make a costly error — such as applying for the wrong product. A simple, well-implemented breadcrumb (e.g., Ana Sayfa > Bireysel Bankacılık > Krediler > Konut Kredisi) would immediately resolve this confusion.

Beyond accessibility, location indicators provide measurable usability and SEO benefits. Breadcrumb structured data (using Schema.org BreadcrumbList) can appear directly in Google search results as rich snippets, improving click-through rates. Clear site structure also reduces bounce rates, as users who understand where they are are more likely to explore related content rather than abandoning the site.

Related Axe-core Rules

WCAG 2.4.8 requires manual testing because automated tools cannot reliably determine whether a location mechanism is present, meaningful, and accessible across all contexts. No axe-core rule directly maps to this criterion. Here is why automation falls short and what manual evaluation must cover:

• Presence of a location mechanism (manual) — An automated scanner can detect whether a breadcrumb element exists in the DOM, but it cannot determine whether that breadcrumb accurately reflects the site's actual information architecture, whether it is placed on every page within a set, or whether it is the correct type of location indicator for the site's navigation model. A tool might find a <nav aria-label="breadcrumb"> element and report no issue, even if the breadcrumb only appears on some pages or contains incorrect hierarchy information.
• Accuracy and completeness (manual) — Automated tools cannot verify that the location information is accurate. A breadcrumb that always shows "Home > Current Page" regardless of the actual hierarchy would pass an automated scan but fail this criterion, because it does not truthfully represent the user's location within the set of pages.
• Programmatic exposure (partially automated) — While axe-core can flag missing aria-current attributes on navigation links in some configurations, it cannot conclusively determine whether the absence of aria-current is a violation of 2.4.8 without understanding the overall site structure and the role of each navigation element.
• Consistency across the page set (manual) — A location mechanism must be available throughout the relevant set of pages, not just on select pages. Automated scans typically evaluate one page at a time and cannot assess whether a mechanism is consistently present across an entire site or section.

How to Test

1. Identify the page set: Determine whether the page under test belongs to a set of related pages with a defined hierarchy (e.g., a multi-level navigation structure, a step-by-step wizard, or a categorized content library). If the page is a standalone document, this criterion may not apply.
2. Run an automated scan as a baseline: Use axe DevTools (browser extension) or Lighthouse in Chrome DevTools to run an accessibility audit. While neither tool directly audits 2.4.8, check for related issues such as missing aria-current attributes on navigation links, unlabeled <nav> landmarks, and missing breadcrumb structure. These findings support — but do not replace — the manual review.
3. Visually inspect for a location mechanism: Look for a breadcrumb trail, a highlighted or visually distinct active link in the navigation, a step counter, or a site map link. Verify that the mechanism accurately reflects the current page's position in the site hierarchy.
4. Test with a screen reader — NVDA + Firefox: Open NVDA, navigate to the page, and press D to cycle through landmarks. Locate the navigation landmark(s) and listen for any indication of the current page or section. Check whether the active navigation item is announced differently (e.g., "current page" or similar, typically conveyed via aria-current="page"). Browse the breadcrumb if present and verify that each level is announced with its link text and that the current location is clearly identified.
5. Test with VoiceOver + Safari (macOS/iOS): Enable VoiceOver (Command + F5), navigate to the breadcrumb or main navigation using VO + U to open the Rotor, and select "Links" or "Landmarks". Listen to how the active navigation item or breadcrumb current item is announced. Verify that the current location is distinguishable from other navigation items.
6. Test with JAWS + Chrome: Use Insert + F7 to open the Links List and Insert + F6 to open the Headings List. Navigate to the breadcrumb or navigation area and confirm that the current page or section is programmatically identifiable. Check that aria-current is read aloud (JAWS announces this as "current" for the relevant element).
7. Test across multiple pages in the set: Navigate through at least three to five pages within the same section or hierarchy and confirm that the location mechanism updates correctly on each page and that it is consistently present throughout the set.
8. Inspect the DOM: Use browser DevTools to check that breadcrumb links have descriptive accessible names, that the current item uses aria-current="page" (for the current page) or aria-current="true" (for the current step in a process), and that the breadcrumb is wrapped in a <nav> element with an accessible label such as aria-label="Breadcrumb".

How to Fix

Missing Breadcrumb Navigation — Incorrect

<!-- No breadcrumb or location indicator present.
     Users have no way to determine their location in the site hierarchy. -->
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
  </ul>
</nav>
<h1>15-inch Laptops</h1>

Missing Breadcrumb Navigation — Correct

<!-- A breadcrumb nav is added above the main content.
     aria-label distinguishes it from main navigation.
     aria-current="page" marks the current location for screen readers.
     The list structure communicates hierarchy. -->
<nav aria-label='Breadcrumb'>
  <ol>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
    <li><a href='/products/laptops/15-inch' aria-current='page'>15-inch Laptops</a></li>
  </ol>
</nav>
<nav aria-label='Main navigation'>
  <ul>
    <li><a href='/'>Home</a></li>
    <li><a href='/products'>Products</a></li>
    <li><a href='/products/laptops'>Laptops</a></li>
  </ul>
</nav>
<h1>15-inch Laptops</h1>

Active Navigation Link Without Programmatic Indicator — Incorrect

<!-- The active link is styled differently in CSS, but there is no
     programmatic signal. Screen reader users cannot distinguish it
     from the other navigation links. -->
<nav aria-label='Site navigation'>
  <ul>
    <li><a href='/about'>About</a></li>
    <li><a href='/services' class='active'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

Active Navigation Link Without Programmatic Indicator — Correct

<!-- aria-current="page" is added to the active link.
     Screen readers will announce this link as "current" or "current page"
     depending on the assistive technology, giving users a clear
     programmatic location signal in addition to the visual styling. -->
<nav aria-label='Site navigation'>
  <ul>
    <li><a href='/about'>About</a></li>
    <li><a href='/services' class='active' aria-current='page'>Services</a></li>
    <li><a href='/contact'>Contact</a></li>
  </ul>
</nav>

Multi-Step Form Without Step Indicator — Incorrect

<!-- A multi-step checkout form with no indication of current step.
     Users cannot determine how far they are through the process
     or how many steps remain. -->
<form>
  <h1>Shipping Information</h1>
  <!-- form fields -->
  <button type='submit'>Next</button>
</form>

Multi-Step Form Without Step Indicator — Correct

<!-- A progress indicator communicates the user's position in the sequence.
     aria-label on the nav provides context.
     aria-current="step" marks the active step for assistive technologies.
     The visible text "Step 2 of 4" is also available for all users. -->
<nav aria-label='Checkout progress'>
  <ol>
    <li><a href='/checkout/cart'>Cart</a></li>
    <li aria-current='step'><strong>Shipping</strong></li>
    <li>Payment</li>
    <li>Confirmation</li>
  </ol>
</nav>
<form>
  <h1>Shipping Information <span>(Step 2 of 4)</span></h1>
  <!-- form fields -->
  <button type='submit'>Next: Payment</button>
</form>

Common Mistakes

• Providing a breadcrumb only on the home page or only on leaf pages: The breadcrumb must be present consistently across all pages within the set. Displaying it only on product detail pages but not on category pages creates gaps in orientation information.
• Using a visually styled active link without adding aria-current="page": A bold or underlined active navigation link communicates location visually, but screen reader users receive no benefit unless aria-current="page" is also present on that element.
• Wrapping the breadcrumb in a <div> instead of a <nav> element: Using a non-semantic container means the breadcrumb is not exposed as a navigation landmark, making it harder for screen reader users to find and interpret.
• Omitting aria-label from the breadcrumb <nav> when a main navigation landmark also exists: Two unlabeled <nav> landmarks on the same page create ambiguity. Screen readers may announce both simply as "navigation," leaving users unable to distinguish between them.
• Using aria-current="true" on a page link instead of aria-current="page": The value page is the semantically correct value for identifying the current page in a navigation context. Using true is less descriptive and may be announced differently or less clearly by assistive technologies.
• Relying solely on a page title to indicate location: A descriptive <title> element (e.g., "Laptops — 15-inch Models | Acme Store") is helpful and required by WCAG 2.4.2, but it does not alone satisfy 2.4.8, which requires a mechanism that conveys position within the page set's structure, not just the name of the current page.
• Building breadcrumbs that reflect URL structure rather than navigational hierarchy: URLs and navigation structures do not always align. Breadcrumbs should reflect the logical information architecture a user would understand, not the underlying URL path, which may be technical or opaque.
• Displaying the breadcrumb as plain text with no links for ancestor levels: If only the current page is shown or ancestor levels are not linked, the breadcrumb loses its utility as both a location indicator and a navigation aid. Ancestor items should be linked to allow users to traverse back up the hierarchy.
• Marking the current breadcrumb item with only a visual separator change instead of aria-current: Changing the color or removing the underline from the last breadcrumb item does not communicate to screen readers that it represents the current page. aria-current="page" must be explicitly added.
• Forgetting to update the location indicator in single-page applications (SPAs) after client-side navigation: In SPAs built with frameworks such as React or Vue, page transitions occur without a full browser reload. If the breadcrumb or active navigation indicator is not programmatically updated on route change, it will display stale location information, which is worse than having no indicator at all.

Relation to Turkey's Accessibility Regulations

Turkey's Presidential Circular 2025/10, published in the Official Gazette No. 32933 on June 21, 2025, establishes binding web and mobile accessibility requirements for a broad range of organizations operating in Turkey. The circular mandates compliance with internationally recognized accessibility standards — effectively adopting the WCAG framework — and applies to a defined set of entity types including public institutions and agencies, e-commerce platforms, banks and financial institutions, hospitals and healthcare providers, telecommunications companies with 200,000 or more subscribers, licensed travel agencies, private transport companies, and private schools authorized by the Ministry of National Education (MoNE).

WCAG 2.4.8 Location is classified as a Level AAA criterion, meaning it is not among the baseline legally required criteria under the circular, which references Level A and Level AA conformance as the minimum threshold. However, the distinction matters in several important ways for organizations covered by the regulation.

First, certain specialized services — particularly those serving users with significant cognitive or navigational challenges, such as healthcare portals for elderly patients or educational platforms for students with learning disabilities — may be expected to exceed the AA baseline in order to genuinely meet the spirit of accessibility obligations under Turkish law and related legislation such as the Law on Persons with Disabilities No. 5378. Implementing 2.4.8 in these contexts demonstrates a substantive, rather than merely procedural, commitment to inclusion.

Second, Turkish public institutions and regulated private entities are increasingly subject to audit and complaint mechanisms. Demonstrating AAA-level compliance — including WCAG 2.4.8 — provides a defensible record of best-practice implementation and reduces regulatory risk in the event of a formal accessibility complaint.

Third, for e-commerce platforms and banks in particular, location indicators such as breadcrumbs have direct commercial value in addition to their accessibility function. A Turkish bank's online mortgage application process that includes clear step indicators and breadcrumb navigation will not only serve users with cognitive disabilities more effectively but will also reduce drop-off rates and support conversion — aligning accessibility investment with measurable business outcomes.

Organizations using the Accsible overlay SDK can leverage its built-in breadcrumb enhancement and aria-current injection features to bring existing sites closer to 2.4.8 conformance without requiring full codebase refactoring. However, for complete and robust compliance — especially for entities covered by Presidential Circular 2025/10 — server-side or build-time implementation of semantic breadcrumb markup and navigation indicators remains the recommended approach, as overlay solutions supplement but do not replace foundational accessible markup.