use UI

Carousel

Also called slider, slideshow, gallery, image rotator

A component showing one item from a set at a time, with controls to move between them.

Example

1 of 4

Front three-quarter

The angle the product is recognised by, shot on a neutral ground.

2 of 4

Detail: the hinge

Machined from one billet, visible only when the lid is half open.

3 of 4

Ports

Two USB-C, one headphone jack, magnetic power on the left edge.

4 of 4

In use

On a desk, at the angle it actually sits when someone is typing.

1 of 4 slides is reachable right now. The other 3 are marked inert, so their “Open full size” buttons are out of the tab order and out of the accessibility tree. That is the honest cost of the pattern — three quarters of this content is not on the page.

Rotation stops while the pointer is over the carousel and while anything inside it has focus, and never starts at all when the system asks for reduced motion.

When to use it

  • The items are a real sequence the user steps through — photos of one product, pages of a tour, frames of a story.
  • Space is genuinely constrained and the items are equivalent, so seeing one at a time loses nothing.
  • The user came to browse this set. A gallery someone opened on purpose is not the same as a banner they scrolled past.

When not to

  • The slides compete rather than continue — three unrelated promotions taking turns in the same box. Beyond the first, they are rarely seen at all.
  • The content matters. Anything a user must find should not depend on them pressing an arrow.
  • You are using it to settle an argument about what goes at the top. A carousel does not resolve that disagreement, it hides it.

Trade-offs

  • Fits a set of equally-weighted items into fixed space without scrolling the page.
  • Right for genuine sequences, where “next” is a meaningful idea.
  • Familiar controls: arrows and dots need no explanation.
  • Hidden slides are effectively unpublished — most people never advance past the first.
  • The most accessibility-demanding common component: roles, labels, autoplay pausing, focus containment, reduced motion, all mandatory.
  • Autoplay competes with reading. Content that moves while being read is a WCAG failure, not a style choice.

Accessibility

What this pattern needs in order to work for everyone.

Keyboard
  • Previous and next are buttons with real names — “Previous slide”, not a bare “‹”.
  • Hidden slides must be unreachable. Anything focusable inside them stays in the tab order unless the slide is `inert` or genuinely removed.
  • If dots select slides, they behave like a tab list: each dot names its destination, and the current one is marked.
Roles and state
  • The container takes `role="region"`, `aria-roledescription="carousel"` and a name, so it is announced as a carousel rather than an anonymous group.
  • Each slide is a `group` with `aria-roledescription="slide"` and a label like “2 of 5” — position is information the visual gives away for free.
  • Autoplay requires a visible pause control (WCAG 2.2.2). It must also pause on hover and on focus, and never restart on its own.
  • Announce slide changes politely, or not at all. A live region set to assertive interrupts everything on every rotation.
Focus
Pressing next keeps focus on the next button. Moving focus into the new slide traps someone who wanted to press it twice. Watch the track's overflow too: `overflow: hidden` is a scroll container, so the browser will scroll it sideways to reveal whatever takes focus — and the carousel stays stuck there. `overflow: clip` creates no scroll container at all, which removes the problem rather than patching it.

In the wild

  • Apple product galleries — A genuine sequence — several views of one product — with no autoplay and clear controls.
  • Netflix rows — Horizontal scrolling rows rather than a rotating carousel: nothing auto-advances and the scrollbar shows how much is left.

Compared with

Side-by-side breakdowns of patterns that solve a similar problem.