Accessibility

The carousel follows the WAI-ARIA Carousel pattern — a set of slides presented one at a time with controls to move between them — and meets WCAG 2.1 AA. An accessible carousel stays operable from the keyboard, tells assistive technology which slide is showing and how many there are, gives every control an accessible name, and — because it advances on a timer — lets people stop that motion so no one is rushed by a disappearing interface.

For designers

• The progress bars, their labels, and the fill that marks progress must all keep accessible contrast on every supported surface, including over imagery — this is why the Contrast scheme flips them to light foreground tokens on dark media. Source: WCAG 1.4.3 Contrast (Minimum).
• Which slide is active must never rest on colour alone — pair it with the thickened, filling bar and the control’s label, so the current position reads without relying on hue. Source: WCAG 1.4.1 Use of Color.
• Each control needs a visible focus ring that stays legible on every surface and is clearly distinct from the hover treatment. Source: WCAG 2.4.7 Focus Visible.
• Because the carousel auto-advances on a timer, give users a visible way to pause or stop the rotation (and pause it on hover and focus) — a self-advancing interface is only accessible when its motion can be halted. Source: WCAG 2.2.2 Pause, Stop, Hide.
• Thin progress bars are easy to miss and hard to tap — keep each control’s target at least 24 × 24 px (aim for 44 px for comfort on touch), and trim the item count before the bars get too small. Source: WCAG 2.5.8 Target Size (Minimum).
• Use semantic colour tokens (the Neutral / Contrast scheme tokens) rather than fixed values, so the indicator adapts correctly across themes and over different backgrounds.

For developers

Wrap the rotating slides in a labelled landmark region announced as a carousel, and present each slide as a discrete group so assistive technology can report position within the set. Build the pagination from native <button> elements, so keyboard and focus behaviour come for free. Because the carousel advances on a timer, provide a keyboard-operable mechanism to pause and stop the rotation, pause it while a control is hovered or focused, and honour prefers-reduced-motion by rendering the active bar full with no animation and not auto-advancing. The per-element roles, names, and states are in the Labelling elements section below.

Keyboard interaction

Key	Action
Tab / Shift + Tab	Move focus to the next / previous slide control
Enter / Space	Activate the focused control to jump to its slide

Labelling elements

Give every element the role, name, and state assistive technology needs.

Carousel region

role="region" with aria-roledescription="carousel" so it announces as a carousel rather than a bare region. Give it an accessible name with aria-label (e.g. “Featured assets”) or aria-labelledby, so listeners know what the rotating set is for.

Slides

Present each slide container as role="group" with aria-roledescription="slide" and a positional name such as aria-label="1 of 3", so people can tell where they are in the set. Document only the slide container — the content slotted inside carries its own component’s semantics.

Slide controls

Each control is a native <button> named with aria-label (e.g. “Go to slide 1”) since its bar carries no text on its own. Mark the current slide’s control with aria-current="true" and disable it so it can’t re-trigger — together they expose the active state.

Source: WCAG 4.1.2 Name, Role, Value.