Carousels, and Whether You Need One at All

Ask the awkward question first, because it saves the most work. Do you need a carousel at all. W3C's own tutorial opens by saying carousels are disputed from a usability point of view, because their content is hard to discover, and then adds the line worth keeping. Making one accessible tends to make it more usable for everybody.

If you can replace it with a static hero or a grid, do that and stop reading. The rest of this page is for when you cannot, which is most of the time, because the carousel came with the theme.

The Rule It Breaks Out of the Box

2.2.2 Pause, Stop, Hide is Level A, and it has two halves that behave differently. Moving, blinking or scrolling content needs a way to pause, stop or hide it when three things are all true. It starts automatically, it lasts more than five seconds, and it is presented in parallel with other content. Auto-updating content gets no five-second grace at all, because W3C's own reasoning is that it makes little sense to auto-update for a few seconds and then stop.

That third condition is the one people miss, and it cuts both ways. A carousel sitting in a page with a heading and body copy beside it is in parallel with other content and is in scope. A full-screen advertisement everybody has to watch before the free content appears is not in parallel with anything, and W3C's own worked example says it needs no pause control at all. There is an essential exception too, which almost never applies to a marketing carousel.

A carousel that autoplays with no pause control is the default configuration of most plugins we find, on most platforms, including the ones bundled with commercial themes. That is a first-thing-to-check rather than a rare finding.

If It Has to Autoplay, the Pause Control Has Rules

The control itself is the easy part. Where it sits and what it says are where implementations go wrong, and both are specified.

• Put the rotation control first in the carousel's tab sequence. W3C calls this essential, and the reason is that it has to precede the rotating content to be findable at all. A pause button after five slides satisfies every other rule on this list and is still unreachable by somebody moving forward through the carousel, which is exactly who it exists for.
• Let its label change with what it will do, from Stop slide rotation to Start slide rotation. A label that changes announces both that the slides can move on their own and whether they are moving now.
• Then do not add aria-pressed. Because the label changes, the control carries no state attribute at all. The two are alternatives. Use a changing label with no aria-pressed, or a fixed label with aria-pressed, and never both, because both means the state gets announced twice in two different words.
• Stop rotating when keyboard focus enters the carousel, and stay stopped. It must not resume unless the user explicitly asks it to. Stop on hover as well.
• Slow enough to read. Five seconds is not long enough for a sentence, let alone for somebody working through a screen magnifier.

One more thing about all the controls, not only the pause button. Activating previous, next or the pause control must not move focus. Leaving focus where it is lets somebody press next four times in a row without hunting for the button again after every press, and it stops the carousel dragging a reader away from where they were.

Honoring a reduced-motion preference is the right thing to do and it is worth being clear that it is not what this criterion asks for. Motion preferences belong to a different criterion, at Level AAA, scoped to animation triggered by interaction. A carousel that respects reduced motion and still autoplays for everybody else with no pause control still fails at Level A.

The Structural Part, Which Is Where the Roles Live

Beyond motion, a carousel is a named region holding a set of slides and some controls, and every part of that has to be announced. The container takes role="region" or role="group", plus aria-roledescription="carousel" so a screen reader says carousel rather than region, plus a name from aria-labelledby pointing at a visible label. Each slide is a group with aria-roledescription="slide". The naming rule catches people out in both places. Because the role description already says carousel, the label must not contain the word carousel, and the same goes for slide.

• Previous and next need names. Previous slide and Next slide, not an unlabeled chevron. Build them as native button elements rather than reimplementing the button pattern, which W3C recommends twice.
• Slide pickers need names and state. Where the slides have real names, use them. Where they do not, a number and set size such as 3 of 10 is an accepted fallback, and it is explicitly a fallback, allowed here because a group cannot carry set position and size the way a tab can. Mark the picker for the current slide with aria-disabled="true", which is preferred over the HTML disabled attribute because it keeps the control in the tab sequence where a screen reader user can still find it. Leave aria-current for pagination, breadcrumbs and navigation, and use aria-selected if you built the pickers as tabs.
• Announce slide changes through a live region when the carousel advances on request. Set that region to off while it is auto-rotating, and to polite when it is not. The reason is specific. If slides rotate on their own and a screen reader user does not know it, they read an element on slide one, press the key for the next element, and hear something from slide two with nothing telling them the context changed.
• Hide the slides that are not showing, properly, so a screen reader cannot read content positioned off screen. An incorrectly hidden slide is disorienting in a way an absent one is not.
• Do not rely on swipe alone. A swipe is a path-based gesture and needs a single-pointer alternative under 2.5.1. A carousel you drag also engages 2.5.7, and W3C's own worked example for that criterion is a news carousel answered with forward and back buttons. Those buttons may be visible, as large arrows, or visually hidden and still operable with a pointer, which is the answer when the design has no room for them.

Swipe-only catches touch-first designs, and the person it stops hardest is not the one you picture. A switch user cannot swipe at all, so a swipe-only carousel is unreachable for them, and that is 2.1.1 Keyboard rather than a pointer rule. W3C's own tutorial maps carousels to four Level A criteria between them, which are structure, keyboard, pause, and name and role.

Three Shapes of Carousel, and One to Avoid

The pattern comes in three published forms and they are not equally kind. The basic one has rotation plus previous and next. The tabbed one builds the slide pickers as a tab list, which puts the whole set of pickers on a single tab stop and lets each slide carry its position and size properly. The grouped one gives every picker button its own tab stop, and W3C says plainly that this is the least friendly of the three for keyboard users.

The grouped shape is what most plugins ship, and it is why a keyboard user tabbing through your homepage hits eight dots before reaching anything. If you are choosing, choose tabbed, and the tabs pattern is the one to build it from.

The Cheapest Test

1. 1Tab to the carousel and confirm the pause control is the first thing you reach inside it.
2. 2Press it and listen. Does the label change to say what it will do next?
3. 3Move focus into the slides. Did rotation stop, and did it stay stopped when you tabbed on?
4. 4Press next and check where focus went. It should still be on the next button.
5. 5Now leave it alone for thirty seconds while reading the first slide, with a mouse nowhere near it, and see whether it moves while you are still on it.

One thing not to test, because we used to suggest it. Do not check whether you can Tab to every slide. A correctly built carousel does not let you, because the slides that are not showing are hidden and the way to reach them is to advance the carousel. Tabbing into all of them is the failure, not the pass.