The inert attribute and focus management in accessible carousels

When people think about building accessible websites, screen readers come to mind first. But the most common accessibility requirement is far more straightforward: full keyboard operability. WCAG 2.1.1, Level A — the most fundamental conformance level of accessibility — requires that every function of a website be reachable without a mouse.

With carousels, this fails in practice almost every time. Not because it's technically difficult, but because focus management is systematically underestimated — and because off-screen slides, when handled incorrectly, silently destroy the tab order.

Keeping Focus in Place

The most important rule in carousel focus management can be stated in one sentence: focus must not shift during navigation.

When a user presses the "Next Slide" button, focus must stay on exactly that button. Not on the new slide. Not on the first link in the new content. On the button. Because only then can the user press the same button again without having to navigate back to it first.

This sounds trivial. In real implementations, it happens constantly — JavaScript sets focus() on a slide element after a slide change, out of well-meaning reflex to place the user "closer to the content." The result: disorientation, broken keyboard navigation, frustration.

The complete keyboard map for a carousel looks like this:

ArrowLeft and ArrowRight act as slide navigation only when the carousel itself or a navigation element holds focus — not when focus is on a link or button inside a slide. This is because arrow navigation in the context of a Tab Pattern is navigable via the outer container. Which in turn means this navigation is not automatically implemented for the Region Pattern.

Losing Focus

Now for the second most common error — and the trickier one, because it's invisible. A carousel usually has more slides than are visible at once. The non-visible slides still exist in the DOM, the hierarchical tree structure listing all HTML elements on the page. And if their contents — links, buttons — remain in the tab order, a keyboard user can focus on elements they can't actually see.

The W3C identifies three strategies to prevent this:

1. The inert HTML attribute — the most robust solution, with a caveat on browser support. inert removes an element and all its children completely from the accessibility tree and the tab order. No manual effort, no forgotten tabindex.

<!-- Off-screen: removed from the accessibility tree -->
<div role="group" aria-roledescription="Slide" aria-label="2 of 5" inert>
  <a href="/product-2">Product 2</a> <!-- not focusable -->
</div>

<!-- Active slide: fully operable -->
<div role="group" aria-roledescription="Slide" aria-label="3 of 5">
  <a href="/product-3">Product 3</a>
</div>

2. aria-hidden="true" + tabindex="-1" — the universal fallback. aria-hidden removes the element from the accessibility tree (a specialized screen reader representation of the DOM). tabindex="-1" removes an HTML element from the tab order. While aria-hidden is set on the parent slides, tabindex must be set on every interactive child element — which quickly becomes cumbersome with complex slide content.

3. CSS interactivity: inert, defined in the CSS Overflow Module Level 5, replicates the functionality of the classic HTML inert attribute. Since current browser support for the CSS variant is incomplete, it's considered experimental. A fallback is required for production use; CSS inert should not be used as the sole solution.

Note — display: none: With scroll-based carousels, this property must not be used to hide slides. Slides must remain in the layout for CSS Scroll Snap and scroll animations to work. inert is the right choice here — it hides the content semantically without removing it from the layout.

The Principle of Self-Determination

There's a reason this topic goes beyond technical correctness. Focus management isn't just a WCAG requirement — it's the digital expression of a fundamental right: self-determination.

A carousel that shifts focus on its own makes a decision on behalf of the user. It says: you should be here now, not there. For a mouse user, that's a mild inconvenience. For a keyboard user, it means losing control of their own navigation.

The tab order works by the same principle. Imagine a user only reaching the navigation after having to skip through the entire content — or finding a large block of text and controls between navigation elements. That sounds absurd to mouse users, but it's everyday life for keyboard users. A small loss of control.

Building accessible experiences means consistently leaving that control in the hands of the user. The button triggers an action. Where focus lands afterward is not for the carousel to decide. In practice: JavaScript must never automatically call focus() after a slide change — unless the user has explicitly navigated to a new content area.

What's Coming Next

Semantics and keyboard navigation are solved — but a carousel still doesn't communicate. When content changes, a screen reader needs to know about it. When, how loudly, and in what form that happens is the topic of Part 4: aria-live, autoplay, and the announcement problem.

➔ When a Screen Reader Should Speak — and When It Shouldn't

Sources: W3C APG, Carousel Pattern · WCAG 2.1.1, Keyboard · Chrome, Accessible Carousel