Breadcrumbs and site navigation accessibility

Navigation is how people find what they came for and tell where they are on a site. W3C's Understanding document for 3.2.3 Consistent Navigation says a repeated, predictable order helps people with cognitive limitations, low vision or intellectual disabilities, and people who are blind. People with low vision who use screen magnification rely on visual cues and page boundaries to find repeated content, and blind users who move through a page in sequence benefit from a consistent order. A menu that changes order between pages makes that harder for each of them.

Headings give the outline inside a page (see our heading structure guide); navigation is how people move between pages. Related guides cover landmarks and regions, skip links and accessible link text.

What WCAG asks of navigation

No success criterion is called "navigation", but several apply. The table lists those that bear on menus, links and breadcrumb trails.

Criteria 2.4.5 and 3.2.3 are judged across a set of pages, not on one page alone. No criterion at Level A or AA requires a breadcrumb trail. W3C's Understanding page for 2.4.8 lists providing a breadcrumb trail (technique G65) among the sufficient techniques for that Level AAA criterion, and the six sufficient techniques it lists for 2.4.5 do not include one. A trail is a usability aid you add where it helps. Which version and level a law or contract asks for depends on the rule that applies; see which WCAG version and conformance levels. This page is general information, not legal advice.

What a breadcrumb trail does

The ARIA Authoring Practices Guide (APG) defines a breadcrumb trail as a list of links to the parent pages of the current page, in hierarchical order, that helps people find their place within a site (APG breadcrumb pattern). W3C's Understanding document for 2.4.8 adds who benefits: people who follow a link straight to a page deep in a set of pages and need to navigate the site to understand it or find related information, and people with a short attention span who may become confused after a long series of navigation steps. In our reading, a trail earns its place on sites with several levels, such as a store with categories or a documentation site. On a site of a handful of pages, one menu does the job.

How to build an accessible breadcrumb trail

The APG's breadcrumb example and MDN's page on aria-current use the same structure. The names are placeholders:

<nav aria-label="Breadcrumb">
  <ol>
    <li><a href="/shop/">Shop</a></li>
    <li><a href="/shop/shoes/">Shoes</a></li>
    <li><a href="/shop/shoes/boots/" aria-current="page">Boots</a></li>
  </ol>
</nav>

• A labeled nav element. The APG puts the trail in a navigation landmark labeled with aria-label or aria-labelledby. The label tells a screen reader user which navigation landmark this is.
• An ordered list. The APG example uses an ol. W3C's menus tutorial says list markup conveys structure to assistive technology, which can report how many items a list holds.
• A link for each step. Every level is a link and the last item is the current page, with aria-current set to page. MDN says the attribute is optional if the current item is not a link, so plain text for the last item also works. Pick one approach and use it on every page.
• Separators drawn in CSS. The APG adds the visual separators with CSS so a screen reader does not announce them. Do not type > or / characters between the links in the HTML.
• No special keyboard behavior. The APG lists none, so Tab moves through the links like any others.

Main navigation: markup and the current page

The site menu uses the same ingredients. W3C's menus tutorial recommends the HTML5 nav element so users can reach the menu directly, a list for the items, and a short, descriptive label so several menus can be told apart.

<nav aria-label="Main">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/products/" aria-current="page">Products</a></li>
    <li><a href="/contact/">Contact</a></li>
  </ul>
</nav>

• Use nav for major blocks only. MDN says a page may have several nav elements, that nav is for a major block of navigation links, and that a footer's list of links often does not need one. MDN's technical summary gives navigation as its implicit role and lists no permitted role for it, so in our reading role="navigation" on a nav is unnecessary. Our landmarks guide covers naming.
• Name links for where they go. Criterion 2.4.4 Link Purpose (In Context) asks that each link's purpose can be determined from its text, or from its text together with its context. A menu item has little context around it, so in our reading the text has to carry the meaning: "Pricing" works and "Click here" does not. An icon-only link, such as a house for "Home", needs a text name, and W3C lists a missing name on an image-only link as failure F89. The February 2026 WebAIM Million found empty links on 46.3% of home pages.
• Mark the current page in code and in style. MDN says aria-current tells an assistive technology user what styling shows sighted users, and to mark only one element in a set, so the attribute and a visible style should agree on one item. W3C's menus tutorial describes two methods: aria-current="page" on a link that stays in place, or replacing the current item's link with plain text plus hidden text such as "Current page:". W3C lists both G128 (current location in navigation bars) and ARIA26 (aria-current) as sufficient techniques for 2.4.8.

Dropdown and mobile menus

Submenus add keyboard and screen reader behavior that a flat list of links does not need. The APG's disclosure navigation example shows one pattern for them:

• Each top-level item that opens a list is a button with aria-expanded ("true" or "false") and aria-controls pointing at its list of links.
• Tab and Shift+Tab move between the buttons and through an open list. Enter or Space toggles a button, and Escape closes the list and returns focus to its button.
• It does not use role="menu", because the navigation does not provide the complex behavior assistive technology expects from a menu widget.

A minimal version, with placeholder names. A script toggles aria-expanded and the hidden attribute:

<li>
  <button type="button" aria-expanded="false" aria-controls="guides-list">Guides</button>
  <ul id="guides-list" hidden>
    <li><a href="/guides/getting-started/">Getting started</a></li>
  </ul>
</li>

W3C's fly-out menu tutorial adds that submenus should not open just from tabbing through the menu, or keyboard users must step through every submenu item to reach the next top-level item. When a parent item must also perform a function of its own, the tutorial suggests a separate button to open and close its submenu and, if possible, the parent's name in that button's label. Other ways to reach the submenu items should exist too, because people with reduced dexterity may struggle with fly-outs.

If a dropdown opens on hover, 1.4.13 Content on Hover or Focus applies, and W3C names sub-menus among the content it covers. In our reading, a hover-only menu also fails keyboard users; our keyboard test and accessible menus guide go further. On a phone-sized layout, the button that opens the menu can follow the same disclosure pattern, in our reading. W3C's menus tutorial says the items that show should appear in the same order and with the same wording and destination.

Keep navigation consistent from page to page

Success criterion 3.2.3 asks that navigation repeated across pages in a set stays in the same relative order, unless the user changes it. W3C defines "same relative order" as the same position relative to other items, so items stay in order even when others are inserted or removed, such as when a submenu expands. It lists presenting links in a different order on different pages as failure F66, and one of its examples is a search field that is last on every page.

The scope is a "set of web pages": pages that share a common purpose and are created by the same author, group or organization. W3C notes that different language versions are different sets, that a checkout flow with a different template may fall outside the set and that a subdomain with separate navigation and authors may be its own set. In practice, build the header from one shared template.

Criterion 3.2.4 covers names and labels. W3C's example of a failure is a search button labeled "Search" on some pages and "Find" on others. Consistent does not mean identical. W3C says a "Search" text label on desktop can become a magnifying glass icon with the accessible name "Search" on mobile.

Give people a second way to find a page

Criterion 2.4.5 asks for more than one way to locate a page. The Understanding document lists six sufficient techniques, and two or more meet the criterion: links to related pages (G125), a table of contents (G64), a site map (G63), a search function (G161), a list of links to all other pages (G126) and links from the home page to all pages (G185). It says users with visual impairments may find search easier than scrolling through a large navigation bar with a screen magnifier or screen reader, and that for a site of three or four pages with every page linked from the home page, links from and to the home page may be sufficient.

A page that is the result of, or a step in, a process is exempt, such as a funds transfer confirmation or search results. In our reading, a menu that links to every page is the G126 list of links, and search or a site map supplies the second way.

Check it yourself

Review at least three pages from different templates:

1. Tab through the header. Every item takes focus in a sensible order, and each dropdown opens with Enter or Space, closes with Escape and returns focus to its button (see the keyboard test and focus order).
2. List the landmarks. With a screen reader or a browser extension, check that the menu and the trail are separate landmarks with different names (see how screen readers read a page).
3. Compare pages. Put the header from three pages side by side and check that order and labels match, then repeat at a narrow width.
4. Find the current page. In the browser's inspector, confirm no more than one aria-current in each set, on the item that has the visible current-page style.
5. Find one page two ways. Reach it through the menu, then through search or a site map.

Then run the free tools. The link text checker lists every link on a page with the name a screen reader announces and flags links with no name, vague text, bare URLs and repeated text that goes to different places. It reads the HTML your server sends, so for a menu a script builds, paste the HTML from your browser's inspector. The accessibility bookmarklet checks the live, rendered page in your browser for links with no accessible name, so it sees links a script adds, and you can run it again after opening a menu. The WCAG audit checklist tracks all 55 Level A and AA criteria and exports CSV, so you can record a status and notes for 2.4.5, 3.2.3 and 3.2.4 and list the pages you sampled. Scan my site for free includes a rule check for links with no accessible name.

None of these can judge consistency. Whether navigation is consistent is a judgment call, not a rule that fires on a pattern in the markup, as our methodology page explains. Order, labels, a second way to find a page and a working trail need a person comparing pages.

Keep it checked

Menus can change whenever someone adds a page, a plugin or a new template. GotAlt checks the pages you monitor every week. It compares the alt text of up to six images per page with the image itself, runs its rule checks, opens monitored pages in a browser for contrast and other checks that need a rendered page (see what we check), and reports what changed. Plans are from $69 a month. Audit my whole site from $69/mo.