Accessible Breadcrumb Navigation
A breadcrumb trail is one of the most-copied patterns on the web, and almost every version gets it nearly right before tripping on a small set of specific mistakes. It also answers to two audiences at once: screen reader users, through ARIA, and search engines, through structured data. This guide covers the semantic markup, marking the current page with aria-current, hiding the separators from assistive technology, keeping the visible trail and the BreadcrumbList data in sync, and shrinking long trails on mobile without breaking either. Copy-ready HTML and JSON-LD mapped to WCAG 2.2.
Why a Breadcrumb Is an Accessibility Feature
A breadcrumb answers one question: where am I in this site? It shows the path from the home page down through the hierarchy to the page you are on, so a visitor who arrived from a search result, deep inside a large site, can see the structure above them and climb back up a level with a single click. That sense of place is easy to take for granted when you can see the whole page at once, and it is exactly what a screen reader user, moving through content one element at a time, does not get for free.
It is worth being precise about what a breadcrumb is, because the name invites a misreading. A breadcrumb is a location trail, not a historytrail. It reflects the page’s fixed position in the site structure, the same on every visit, not the sequence of pages this particular user happened to click through to get here. The browser back button already handles history. A breadcrumb is also not a progress indicator for a multi-step form or checkout; that is a separate pattern with its own markup. Keeping the trail to a genuine hierarchy is what makes it predictable, and predictability is half of accessibility.
The idea that ties this guide together
A breadcrumb has to satisfy two separate contracts with two different readers. The first is with assistive technology, and it is written in ARIA: a named navigation landmark wrapping an ordered list, with the current page marked by aria-current. The second is with search engines, and it is written as BreadcrumbList structured data, which is what turns a raw URL into a breadcrumb trail in the search result. These are independent. You can nail one and fail the other, and because they are maintained in different places they quietly drift apart. A good breadcrumb keeps both correct and keeps them describing the same trail.
Breadcrumbs earn their place on sites with real depth: a store with categories and subcategories, documentation with nested topics, a knowledge base. On a flat site with a handful of top-level pages they add clutter without adding orientation, so this is a pattern to use where the hierarchy is deep enough to get lost in. Where they do belong, they are a small, cheap addition that helps everyone, and getting the markup right is mostly a matter of a few semantic choices, which the rest of this guide walks through.
How Breadcrumbs Map to WCAG 2.2
The highlighted row, 2.4.8 Location, is the criterion breadcrumbs were invented to satisfy: helping a user understand where the current page sits within the site. It is a AAA enhancement, so it is optional, but the rest of the table is not. Once you choose to build a breadcrumb, it has to meet the A and AA criteria that apply to any piece of navigation, from correct structure to a visible focus ring.
| Criterion | Level | How it applies to breadcrumbs |
|---|---|---|
| 2.4.8 Location | AAA | A breadcrumb is the standard technique for showing where the current page sits in the site hierarchy, which is exactly what this criterion asks for. |
| 1.3.1 Info and Relationships | A | The trail is an ordered list inside a named navigation region, and which crumb is current is exposed in the markup, not just implied by styling. |
| 4.1.2 Name, Role, Value | A | The navigation landmark carries an accessible name, and the current page is conveyed as a state with aria-current="page", not as visual weight. |
| 2.4.4 Link Purpose (In Context) | A | Each crumb’s link text names the level it leads to, so the destination is clear from the link and its place in the trail. |
| 2.4.5 Multiple Ways | AA | Breadcrumbs are one accepted way to locate a page within a set, counting alongside site search and a sitemap toward providing more than one route to content. |
| 1.4.1 Use of Color | A | The current crumb and the separators must not be distinguished by color alone; the current state comes from aria-current and a non-color cue. |
| 2.4.7 Focus Visible | AA | Every crumb that is a link takes keyboard focus and shows a clearly visible focus indicator as the user tabs across the trail. |
Each criterion links to its full reference and interactive demo. The complete WCAG 2.2 criteria are one click away.
1. The Minimum Viable Accessible Breadcrumb
Almost all of a breadcrumb’s accessibility comes from four markup decisions, and none of them needs JavaScript. Wrap the trail in a <nav> with an accessible name. Put the crumbs in an ordered list, because their sequence from root to current page is meaningful. Make every ancestor crumb a link. Mark the final crumb, the current page, with aria-current="page". Here is the whole pattern:
<nav aria-label="Breadcrumb">
<ol>
<li><a href="/">Home</a></li>
<li><a href="/shoes/">Shoes</a></li>
<li><a href="/shoes/running/">Running</a></li>
<li>
<a href="/shoes/running/trailblazer/" aria-current="page">
Trailblazer 3
</a>
</li>
</ol>
</nav>Each decision is doing real work. The <nav aria-label="Breadcrumb"> exposes a navigation landmark with a distinct name, so a screen reader user can find and skip to the breadcrumb, and can tell it apart from the main menu, which is also a navigation landmark. Write the label as Breadcrumb, not Breadcrumb navigation: the role already contributes the word navigation, so the longer label is announced as “Breadcrumb navigation, navigation.”
The <ol>is deliberate. A breadcrumb is an ordered sequence, home first and current page last, and the ordered list is what carries that meaning to assistive technology. It also gives the user an item count, so a screen reader can announce “list, four items” and let them move crumb by crumb. An unordered list works mechanically, and some famous design systems ship one, but <ol> is the honest choice for content whose order is the point.
Everything except the last crumb is a link that climbs one level of the hierarchy. The last crumb names the current page and carries aria-current="page", which section three covers in full. That single attribute is what tells a non-visual user which crumb is the end of the trail, and it is the piece most breadcrumbs leave out.
2. The Separators Are Decoration: the Number One Bug
The most common breadcrumb accessibility bug is not a missing attribute; it is the little slash, chevron, or arrow between the crumbs. Those separators are purely visual. They tell a sighted user where one crumb ends and the next begins, but the list structure already conveys that to assistive technology, so the separator conveys nothing new. When it is real text in the markup, a screen reader dutifully reads it, and the trail comes out as “Home, slash, Shoes, slash, Running, slash, Trailblazer 3.” The fix is to make sure the separator never reaches the accessibility tree.
Best: draw it with CSS
The cleanest approach keeps the separator out of the DOM entirely, by generating it with a CSS pseudo-element. Content added through ::before or ::after is presentational and is not exposed to assistive technology, so there is nothing for a screen reader to read:
<nav aria-label="Breadcrumb">
<ol class="breadcrumb">
<li><a href="/">Home</a></li>
<li><a href="/shoes/">Shoes</a></li>
<li><span aria-current="page">Running</span></li>
</ol>
</nav>
<style>
.breadcrumb { display: flex; flex-wrap: wrap; list-style: none; }
/* The separator is drawn before each crumb except the first. */
.breadcrumb li + li::before {
content: "/";
margin: 0 0.5rem;
color: #64748b; /* decorative only */
}
</style>Acceptable: hide it with aria-hidden
Sometimes the separator has to be in the markup, for example a designed chevron delivered as an inline SVG. In that case, hide it from assistive technology with aria-hidden="true". For an inline SVG, also add focusable="false", because in some browsers an SVG can otherwise become a stray tab stop:
<ol class="breadcrumb">
<li><a href="/">Home</a></li>
<li aria-hidden="true">
<svg aria-hidden="true" focusable="false" width="16" height="16"> ... </svg>
</li>
<li><a href="/shoes/">Shoes</a></li>
</ol>Two rules apply whichever technique you use. Never put the separator inside the link, or it becomes part of the link text and, worse, part of the clickable target. And remember the separators fall under 1.4.1 Use of Color only in the sense that they must never be the only thing distinguishing crumbs; since the list already separates them structurally, a decorative separator is safe as long as it is hidden from assistive technology.
3. Marking the Current Page with aria-current
aria-currentis a state that marks the single item in a set that represents the user’s current position. In a breadcrumb it belongs on exactly one crumb, the last one, the page you are on. A screen reader announces that crumb as “current page,” which is how a non-visual user knows the trail has reached its end. Leave it off and the last crumb is just another item; put it on more than one crumb and it stops meaning anything.
Use the value page, not the generic true. Both are valid, but aria-current has several token values for different kinds of set, and pageis the one that means “the current page in a set of pages,” which is precisely a breadcrumb:
| Value | Use it for |
|---|---|
page | The current page within a set of pages. This is the breadcrumb value, and also the one for the active link in a site menu. |
step | The current step in a multi-step process, such as a checkout progress indicator. Not a breadcrumb. |
location | The current location in a visual flow such as a diagram or map, where page does not fit. |
true | The current item when none of the specific tokens fits. Valid in a breadcrumb, but page is more precise. |
date, time | The current date or time within a calendar or scheduler. |
Link or plain text?
The current crumb can be a link to the current page or plain text, and both are accepted. The WAI-ARIA Authoring Practices example renders it as a link carrying aria-current="page", which keeps every crumb visually and behaviorally consistent. Many teams instead render the last crumb as a plain <span> with aria-current="page", on the reasoning that a link to the page you are already on does nothing useful. Either is fine; the two things that are not fine are leaving the current page unmarked, and making it a link to some other page. What matters is the state, not the element.
<!-- As a link (APG example) -->
<li><a href="/shoes/running/" aria-current="page">Running</a></li>
<!-- As plain text (also correct) -->
<li><span aria-current="page">Running</span></li>One caution that ties back to 1.4.1 Use of Color: do not let bold text or a color be the only signal that a crumb is current. A sighted user who cannot perceive the weight or hue, and every screen reader user, needs the state to come from aria-current. Many designs also style the current crumb with aria-current as the CSS hook, for example [aria-current="page"] { font-weight: 600; }, which keeps the visual and the programmatic cue from ever disagreeing.
4. The Second Contract: BreadcrumbList Structured Data
The ARIA markup makes the breadcrumb work for people using assistive technology. It does nothing for search engines, which read a separate representation: BreadcrumbList structured data. This is the markup that lets Google replace the bare URL in a search result with a readable trail like Home › Shoes › Running, and it is worth adding on any site where breadcrumbs matter for discoverability. The recommended format is JSON-LD, a script block that describes the trail as data, kept separate from the visible HTML:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "BreadcrumbList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "Home", "item": "https://example.com/" },
{ "@type": "ListItem", "position": 2, "name": "Shoes", "item": "https://example.com/shoes/" },
{ "@type": "ListItem", "position": 3, "name": "Running", "item": "https://example.com/shoes/running/" }
]
}
</script>Each ListItem has a position counting from one, a name that matches the crumb text, and an item URL. The last item can omit its item URL to signal the current page, though including it is also accepted. This is exactly the shape the BreadcrumbStructuredData component on this site emits for every page, including this one, which you can confirm by viewing source.
The rule that connects the two contracts
The structured data must describe the same trail the user can see. Google’s guidelines require breadcrumb markup to reflect visible content, so a BreadcrumbList that lists pages the on-screen breadcrumb does not show, or names them differently, is a structured-data violation as well as a sign the two representations have drifted. The failure mode is mundane: someone updates the visible labels, or reorders the hierarchy, and forgets the JSON-LD, so the accessible trail and the SEO trail slowly diverge. The reliable defense is to generate both from one source.
In a component-based codebase that source is usually a single array of crumbs that feeds both the rendered list and the JSON-LD, so they cannot disagree by construction:
// One array of crumbs is the single source of truth.
const crumbs = [
{ name: "Home", url: "/" },
{ name: "Shoes", url: "/shoes/" },
{ name: "Running", url: "/shoes/running/" },
]
// The visible list and the BreadcrumbList JSON-LD both read from it,
// so the accessible trail and the SEO trail always match.
<nav aria-label="Breadcrumb">
<ol>
{crumbs.map((crumb, i) => {
const isLast = i === crumbs.length - 1
return (
<li key={crumb.url}>
{isLast
? <span aria-current="page">{crumb.name}</span>
: <a href={crumb.url}>{crumb.name}</a>}
</li>
)
})}
</ol>
</nav>You may also see breadcrumbs marked up inline with microdata or RDFa attributes woven into the HTML. That still works, but JSON-LD is the format Google recommends and the easiest to keep correct, precisely because it lives in one place rather than being scattered across the markup. Whichever you choose, the accessible HTML and the structured data are two different jobs: the ARIA is for the screen reader, the BreadcrumbList is for the crawler, and neither one substitutes for the other.
5. Long Trails: Truncation and Responsive Breadcrumbs
A five-level trail does not fit a narrow phone screen, and the usual answer is to collapse the middle, showing the root, an ellipsis, and the last crumb or two, so it reads as Home › … › Trailblazer 3. Done carelessly, this quietly breaks both contracts at once, so it is worth doing deliberately.
The rule is simple: collapse the trail visually, but keep every crumb in the DOM. If you solve the space problem by deleting the middle crumbs from the markup, you remove them from the screen reader trail and from the BreadcrumbList data in the same stroke, so a non-visual user and a search crawler both lose the middle of the hierarchy. Instead, hide the middle crumbs with CSS and expose them behind a control:
<nav aria-label="Breadcrumb">
<ol>
<li><a href="/">Home</a></li>
<!-- A real button, not a bare ellipsis, reveals the hidden crumbs -->
<li>
<button type="button" aria-expanded="false" aria-controls="crumb-rest">
<span aria-hidden="true">…</span>
<span class="sr-only">Show full path</span>
</button>
</li>
<!-- Present in the DOM, visually collapsed until expanded -->
<li id="crumb-rest" hidden><a href="/shoes/">Shoes</a></li>
<li><a href="/shoes/running/">Running</a></li>
<li><span aria-current="page">Trailblazer 3</span></li>
</ol>
</nav>The collapse control has to be a real <button> with an accessible name, here provided by an .sr-only label because the visible glyph is only an ellipsis. It carries aria-expanded so its state is announced, and activating it reveals the hidden crumbs. That behavior is a small disclosure widget; the accordion and disclosure guide covers the pattern in depth. A simpler alternative that avoids the button entirely is to let the row wrap onto two lines, or to make the breadcrumb a horizontally scrollable strip, keeping every crumb visible and reachable.
Whatever the approach, the breadcrumb must not force the page to scroll horizontally at 320 pixels wide, which would fail 1.4.10 Reflow, which keeps content usable when zoomed. Wrapping and a self-scrolling strip both satisfy that; a trail that pushes the whole layout wider than the viewport does not.
6. What a Breadcrumb Sounds Like to a Screen Reader User
It helps to know what all of this markup adds up to at the other end. A screen reader user rarely reads a page top to bottom; they move by landmark and by list. Because the breadcrumb is a named navigation landmark, it shows up in the landmarks list as “Breadcrumb navigation,” and the user can jump straight to it, exactly as covered in the landmarks and page structure guide.
Inside it, a well-built trail is announced as an ordered list with a known number of items, and each item reads as its link text with no separator noise: “Home, link. Shoes, link. Running, link. Trailblazer 3, current page.” That last phrase, current page, is the payoff of aria-current, and it is the difference between a user knowing they have reached the end of the trail and wondering whether there is another crumb coming. Compare that to a broken trail, where the same content might read as “Home, slash, Shoes, slash, Running, slash, Trailblazer 3” with no list, no current-page cue, and a slash after every word. The markup choices in this guide are what separate the two.
The commands differ by screen reader: NVDA and JAWS reach the breadcrumb through the landmark and list navigation keys, while VoiceOver uses the rotor. In every case the experience depends on the same few attributes being present, which is why testing with a real screen reader, covered next, is the check that matters.
7. Testing a Breadcrumb
Keyboard
Tab across the trail. Every ancestor crumb should take focus in order, show a clearly visible focus indicator, and activate with Enter. If the current crumb is plain text it is correctly skipped; if it is a link, it takes focus like the others. If you built a collapse control, it should be reachable by Tab, operable with Enter or Space, and it should reveal the hidden crumbs when activated.
Screen reader
This is the test that catches the real bugs. Open the landmarks list and confirm the breadcrumb appears with its name, distinct from the main navigation. Move into it and listen: you should hear an ordered list, each crumb as its link text, the current page announced as “current page,” and crucially no separators read aloud. If you hear “slash” between crumbs, your separators are not hidden. If you never hear “current page,” the aria-current is missing.
Structured data
Validate the BreadcrumbListJSON-LD with Google’s Rich Results Test or the Schema.org validator, and then do the check no tool performs for you: read the structured data next to the visible trail and confirm they list the same pages, in the same order, with the same names.
What tools catch, and what they do not
Automated checkers such as axe and WAVE will flag a navigation landmark with no accessible name and other mechanical faults, and the Rich Results Test will flag malformed structured data. What none of them can judge is whether the trail is right: whether it reflects the true hierarchy, whether the current page is the one actually marked, whether the separators are meaningfully hidden, or whether the visible trail and the JSON-LD agree. As the automated versus manual testing guide puts it, the machine gets you to valid markup and a person decides whether it is correct. For where this fits in a full review, see the accessibility audit guide.
Common Breadcrumb Mistakes & How to Fix Them
These are the errors that turn up most in real breadcrumb audits. Most come back to two habits: treating the separators as content instead of decoration, and letting the visible trail, the ARIA, and the structured data fall out of sync.
| Anti-pattern | Why it fails | The fix |
|---|---|---|
| The separator is real text, so a screen reader reads "Home slash Products slash Shoes". | The slash, chevron, or arrow is decoration that conveys nothing the list already conveys, and reading it aloud clutters every crumb (weakens 1.3.1). | Draw separators with a CSS ::before or ::after pseudo-element, or if they must be in the markup, add aria-hidden="true" (and focusable="false" on an SVG). |
| The breadcrumb nav has no accessible name. | It announces only as "navigation," identical to the main menu and any other nav, so a screen reader user cannot pick it out of the landmarks list (fails 4.1.2). | Add aria-label="Breadcrumb" to the nav, without the word navigation in the label since the role already supplies it. |
| The current page is unmarked, or is a link to a different page. | Nothing tells a screen reader user which crumb is the page they are on, so the trail has no endpoint and the location cue is lost (weakens 1.3.1 and 4.1.2). | Mark the last crumb with aria-current="page", and make it plain text or a link to the current page, never a link elsewhere. |
| The crumbs are divs and spans with no list. | The trail has no programmatic structure and no item count, so assistive technology cannot present it as an ordered set (fails 1.3.1). | Use an ordered list: a nav wrapping an ol, with one li per crumb, so the sequence is exposed. |
| The current crumb is distinguished only by bold text or a color. | A user who cannot perceive the color or weight gets no cue about which page is current, and a screen reader gets nothing at all (fails 1.4.1). | Convey the current page with aria-current="page" plus a visible non-color cue, not styling alone. |
| The BreadcrumbList structured data lists a different trail than the one on screen. | Google requires breadcrumb markup to match visible content, so a mismatch is a structured-data violation and a sign the two representations have drifted. | Generate the visible list and the JSON-LD from a single array of crumbs so they cannot disagree. |
| On mobile the middle crumbs are deleted from the markup to save space. | Removing them from the DOM strips them from the screen reader trail and from the structured data, and an ellipsis with no control leaves nothing to expand. | Keep every crumb in the DOM and collapse the middle behind a real button with a name like "Show full path," and let the row wrap or scroll. |
The Accessible Breadcrumb Checklist
- Wrapped in a named landmark. The trail sits inside
<nav aria-label="Breadcrumb">, so it is a distinct navigation landmark, without the word navigation in the label. - An ordered list. The crumbs are an
<ol>with one<li>each, because the sequence from root to current page is meaningful. - Ancestors are links. Every crumb except the current page is a link that climbs one level of the hierarchy, with clear text.
- The current page is marked. The last crumb carries
aria-current="page", and it is either plain text or a link to the current page, never a link elsewhere. - Separators are decorative. The slash or chevron is drawn with CSS or hidden with
aria-hidden="true", and is never read aloud or placed inside a link. - Not color alone. The current crumb is conveyed by
aria-currentplus a non-color cue, not by weight or hue on its own. - Focus is visible. Each crumb link takes keyboard focus in order and shows a clearly visible focus indicator.
- Structured data matches. The
BreadcrumbListJSON-LD lists the same pages, in the same order, with the same names as the visible trail. - Long trails collapse safely. On small screens the middle crumbs stay in the DOM and collapse behind a real button, and the row never forces horizontal page scrolling.
- Verified with a screen reader. The Breadcrumb landmark announces an ordered list, each crumb, and the current page, with no separator noise.
Breadcrumbs Are One Part of a Page’s Structure
A breadcrumb is a named navigation landmark, so it sits inside the wider system of landmarks and headings that a screen reader user navigates by. See how the whole structure fits together, and the criterion breadcrumbs exist to satisfy.
Frequently Asked Questions
Should a breadcrumb use an ordered list or an unordered list?▾
An ordered list. The whole point of a breadcrumb is that the items run in a meaningful sequence, from the site root down to the current page, so an ol communicates that order to assistive technology in a way a ul does not. Some very well-known examples use a ul, and a screen reader user can still read them, but ol is the more correct choice because the position of each crumb in the trail carries meaning. Wrap the list in a nav element with an accessible name, put one li per crumb, and let the ordered list express the hierarchy.
Do I need aria-label on the breadcrumb nav?▾
Yes, if the page has more than one navigation region, which almost every page does. A nav element exposes the navigation landmark, and two unnamed navigation landmarks both announce simply as navigation, so a screen reader user browsing the landmarks list cannot tell the breadcrumb apart from the main menu. Give it aria-label="Breadcrumb", and it becomes Breadcrumb navigation in the landmarks list. Do not write aria-label="Breadcrumb navigation", because the role already contributes the word navigation and the user would hear it twice. The single word Breadcrumb is the conventional and correct name.
Should the last breadcrumb be a link?▾
It can be either a link to the current page or plain text, and both are accepted. What matters is that the current page is marked with aria-current="page" so assistive technology announces it as the current location, and that it is not a link to a different page. The WAI-ARIA Authoring Practices example uses a link to the current page carrying aria-current="page"; many teams instead render the last crumb as a plain span with aria-current="page", which avoids a link that navigates to the page you are already on. Choose one, keep it consistent, and never distinguish the current crumb by bold or color alone.
What is aria-current="page" and where does it go?▾
aria-current is a state that marks the one item in a set that represents the user's current position, and the value page is the variant for the page within a navigation trail. In a breadcrumb it goes on the last crumb only, the one that names the page you are on. A screen reader announces that item as current page, which is how a non-visual user knows where the trail ends. Put it on exactly one crumb; putting aria-current on every crumb, or using it on more than one, defeats the purpose. The value should be page for breadcrumbs, not the generic aria-current="true", because page is more precise, although true is still valid.
How do I make breadcrumb separators accessible?▾
Treat the separators as decoration, because that is what they are. A slash, chevron, or arrow between crumbs conveys nothing that the list structure does not already convey, so it must not be read aloud. The cleanest technique is to draw the separator with CSS, using a ::before or ::after pseudo-element on each list item, so it never enters the accessibility tree at all. If the separator has to live in the markup, for example an inline SVG icon, give it aria-hidden="true" (and focusable="false" on an SVG) so screen readers skip it. Never place the separator inside the link text, and never leave a bare slash as real text, or users will hear Home slash Products slash Shoes.
Are breadcrumbs required by WCAG?▾
No single criterion says every page must have a breadcrumb. Breadcrumbs are a technique, not a requirement. They are the standard way to satisfy 2.4.8 Location, which is a AAA criterion about helping users understand where they are within a set of pages, and they count as one of the ways to locate content under 2.4.5 Multiple Ways at AA (alongside site search and a sitemap). So while you are not obligated to use breadcrumbs, when you do, the markup has to meet the A and AA criteria that apply to any navigation: correct structure under 1.3.1, an accessible name and current state under 4.1.2, clear link text under 2.4.4, no reliance on color under 1.4.1, and a visible focus indicator under 2.4.7.
Do breadcrumbs need structured data, and does it help SEO?▾
Structured data is separate from accessibility and serves a different consumer. The ARIA markup is read by screen readers; the BreadcrumbList JSON-LD is read by search engines, and it is what lets Google show a breadcrumb trail instead of a raw URL in the search result. Adding it is optional but worthwhile for discoverability. The rule that connects the two is that the structured data must describe the same trail the user can see on the page. Google requires breadcrumb markup to reflect visible content, so a BreadcrumbList that lists pages the breadcrumb does not show, or names them differently, is both a structured-data violation and a signal that your two representations have drifted apart. Generate the visible list and the JSON-LD from one source so they cannot disagree.
How should breadcrumbs behave on a small screen?▾
Long trails have to fit narrow viewports without breaking the trail or the layout. The safe pattern is to keep every crumb in the DOM and collapse the middle of the trail visually, showing the root, an expandable control, and the last one or two crumbs, so it reads as Home, ellipsis, Current. The collapse control must be a real button with an accessible name such as Show full path, not a bare ellipsis that does nothing, and activating it should reveal the hidden crumbs. Do not solve the space problem by deleting the middle crumbs from the markup, because that removes them from the screen reader trail and from the structured data at the same time. Also make sure the row can wrap or scroll rather than forcing horizontal page scrolling, which would fail 1.4.10 Reflow.
Essential Accessibility Resources
Comprehensive tools, checklists, and guides to help you create inclusive digital experiences