Accessible Breadcrumb Navigation: A Plain-English Guide for Non-Developers

You have almost certainly used a breadcrumb trail, even if you never called it that. It is the little row of links near the top of a page that shows the path you took to get there: Home > Shop > Men’s Shoes > Trail Runners. On a big site, breadcrumbs are one of the quietest, most useful things you can offer a visitor. They answer the question “where am I, and how do I get back?” without making anyone hunt for it.

But like most helpful patterns on the web, breadcrumbs only do their job if everyone can use them — including people who browse with a screen reader, navigate with a keyboard instead of a mouse, or zoom the page to 200% or more. When breadcrumbs are built carelessly, they turn into a confusing pile of links that announce themselves wrong, trap keyboard users, or vanish entirely on a phone. When they are built well, they quietly help every single visitor.

This guide is for the non-developer — the shop owner, the marketer, the person who keeps the website running — who wants to understand what “accessible breadcrumbs” actually means and how to check their own. No DevTools required.

Why breadcrumbs matter more than they look like they should

Breadcrumbs seem like a small cosmetic detail, but they carry real weight for a few different groups of people.

For screen reader users, orientation is everything. Someone who cannot see the whole page at a glance relies on structured cues — headings, landmarks, and yes, breadcrumbs — to build a mental map of where they are. A well-marked breadcrumb trail is announced as “navigation, breadcrumb,” and the user instantly knows they can jump up a level or two without scrolling around blindly.

For people with cognitive disabilities, or honestly anyone who is tired, distracted, or shopping on their phone during a commute, breadcrumbs reduce the mental effort of understanding a site’s structure. They make the hierarchy visible so nobody has to hold it in their head.

For keyboard users — including people with motor disabilities who cannot use a mouse — breadcrumbs offer a fast, predictable way to move back up the tree without tabbing through an entire menu.

And there is a business bonus: search engines read breadcrumbs too. Google displays breadcrumb trails in search results and uses them to understand your site structure, so getting them right helps both accessibility and SEO. That overlap between accessibility and search visibility shows up again and again — we wrote more about it in our guide on the SEO benefits of accessibility.

What a good breadcrumb actually is (in plain terms)

Under the hood, an accessible breadcrumb trail is really just three simple ideas working together. You do not need to write any of this yourself, but knowing what “good” looks like helps you spot when something is broken.

  1. It is marked as navigation. The whole trail sits inside a navigation region that is labeled “Breadcrumb.” That label is what lets a screen reader announce it as a distinct piece of navigation, separate from your main menu. Without it, the trail is just a stray row of links floating in the page.

  2. It is an ordered list of links. Because breadcrumbs represent steps in a sequence — from the home page down to where you are now — the links belong in an ordered list. This tells assistive technology “these items have an order and there are, say, four of them,” which is exactly the information a screen reader user wants.

  3. The current page is marked as current — and is not a link. The last item in the trail is the page you are already on. It should be plain text, not a clickable link, and it should be marked as the “current” page so screen readers announce it that way. Making the current page a link is a classic mistake: it invites people to click a link that just reloads the page they are already looking at.

That is genuinely the whole recipe. Navigation region with a label, an ordered list of links, and a clearly-marked current page. Everything else is styling.

The five breadcrumb problems we see most often

When we scan real small-business sites, the same handful of breadcrumb issues come up over and over. Here is how to recognize each one and what to ask for.

1. The separator gets read out loud

Designers love to put a symbol between breadcrumb items — a slash, a chevron >, or a little arrow. That is fine visually. The problem starts when that symbol is real text sitting between the links, because some screen readers will read it aloud: “Home, greater-than, Shop, greater-than, Men’s Shoes.” Multiply that by every page and it becomes exhausting noise.

The fix: the separator should be added with CSS or marked so assistive technology ignores it, so screen reader users hear “Home, Shop, Men’s Shoes” cleanly. You can check this yourself by listening to your own breadcrumbs with a screen reader — our guide on how to test your site with VoiceOver, no coding required walks you through it on a Mac.

2. The current page is a link (or is missing entirely)

Two variations of the same problem. Sometimes the last crumb — the page you are on — is a working link, which is pointless and mildly confusing. Other times the current page is left out of the trail altogether, so the breadcrumb stops one level short and never tells you where you actually are.

The fix: include the current page as the final crumb, render it as plain text rather than a link, and mark it as the current page so screen readers announce it. This is a small change but it removes a genuine point of confusion.

3. The whole trail is invisible to screen readers

This happens when breadcrumbs are built as a plain row of links with no navigation label and no list structure — just text and links dropped into the page. Visually it looks like a breadcrumb. To a screen reader, it is an anonymous cluster of links with nothing tying them together and no announcement that this is breadcrumb navigation at all. The user has no way to know they have found the trail.

The fix: wrap the trail in a labeled navigation region and use a proper list. This is the single most important fix, because it is the difference between “breadcrumbs exist” and “breadcrumbs exist for everyone.”

4. Breadcrumbs disappear or overflow on mobile

On a narrow phone screen, a long trail like Home > Shop > Women > Outerwear > Waterproof Jackets does not fit. Some sites solve this by hiding breadcrumbs entirely on mobile. Others let the trail overflow off the side of the screen, or collapse it into something that only works with a precise mouse hover — which a touch or keyboard user can never trigger.

The fix: keep breadcrumbs available on mobile, and if space is tight, shorten them thoughtfully — for example, showing the immediate parent and a way to expand the rest — rather than deleting them or hiding them behind a hover. Whatever collapsing pattern you use has to work by tapping and by keyboard, not just by hovering a mouse. This is the same principle we cover in our broader mobile website accessibility guide.

Breadcrumb text is often small and low-contrast — pale gray on white — because it is treated as secondary information. But “secondary” does not mean “invisible.” If the text falls below the required contrast ratio, a large group of older and low-vision visitors simply cannot read the trail, which defeats the entire purpose of providing orientation.

The fix: make sure breadcrumb text and links meet the standard 4.5:1 contrast ratio against their background, and that links are distinguishable from the plain current-page text (not by color alone). If you are unsure how to check this, our color contrast guide explains how to test it with free tools.

How to check your own breadcrumbs in five minutes

You do not need to be technical to audit your breadcrumbs. Here is a quick, non-developer checklist you can run right now.

  • Look for them. Do your category, product, or deep content pages even have breadcrumbs? If not, they may be worth adding on any site more than two levels deep.
  • Tab through them. Click at the top of a page and press the Tab key. Each breadcrumb link should receive a clearly visible focus outline as you move through it, and pressing Enter should follow the link. If focus skips them or you cannot see where you are, that is a problem.
  • Check the last crumb. Is the page you are currently on shown at the end of the trail, and is it plain text rather than a clickable link? It should be.
  • Read the contrast. Squint at the breadcrumb text. If it is barely visible to you on a good screen, it is invisible to a lot of your visitors.
  • Listen to them. Turn on VoiceOver (Mac) or NVDA (Windows) and navigate to the breadcrumb area. You want to hear something like “Breadcrumb, navigation, list, four items” — not a stream of “greater-than, greater-than” or a nameless bundle of links.
  • Shrink the window. Narrow your browser to phone width. Do the breadcrumbs survive, wrap, or collapse gracefully — or do they vanish or run off the edge?

If any of those checks fail, you now know exactly what to hand to whoever maintains your site. And most of these are small, low-risk fixes — not a redesign.

If your site falls under the Americans with Disabilities Act, the European Accessibility Act, or WCAG-based standards, breadcrumbs are not exempt just because they are small. Navigation that some visitors cannot perceive or operate is exactly the kind of barrier these rules exist to remove. Broken breadcrumbs rarely trigger a lawsuit on their own, but they are a visible signal of how much care went into the rest of the site — and they are genuinely easy to get right. Fixing them is one of the higher-return, lower-effort items on any accessibility to-do list.

The good news is that breadcrumbs are one of those rare cases where the accessible version is also the better version for everybody. A clean, well-labeled, readable trail helps your screen reader users, your keyboard users, your mobile shoppers, your search ranking, and the person who just wants to click back up to the category page. There is no trade-off to make here — just a small amount of care that pays off across the board.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.