Accessible carousels and sliders

A carousel shows a collection of items one at a time. W3C's carousels tutorial notes that carousels are also called slideshows and sliders. Built carelessly, one fails people in three ways: it moves, it hides most of its content at any moment, and its controls are custom parts that need names and keyboard support. W3C's explanation of success criterion 2.2.2, Pause, Stop, Hide says content that moves or auto-updates can be a barrier to anyone who has trouble reading stationary text quickly or tracking moving objects, and moving content can be a severe distraction for some people.

The tutorial also says carousels are disputed from a usability perspective, because their content can be hard to discover. In GotAlt's reading, anything a visitor must see should also be reachable without waiting for a slide. If you keep a carousel, the rest of this guide is the checklist. None of GotAlt's checks tests whether one pauses or works from the keyboard, so it ends with a manual test.

What W3C asks of a carousel

The tutorial names four requirements: users can pause movement, everything works from the keyboard, changes are communicated to all users including screen reader users, and focus is managed in a comprehensible way.

The tutorial's Styling part lists 2.5.5 Target Size (Enhanced, Level AAA) for button size, not the Level AA criteria 2.5.7 and 2.5.8 that WCAG 2.2 added, which bear on carousels and are covered under touch below. The second source here is the carousel pattern in the ARIA Authoring Practices Guide (APG), which gives detailed roles, labels and keyboard behavior.

Does a carousel have to pause?

If it advances on its own, yes: it needs a way to pause, stop or hide it. W3C's tutorial lists 2.2.2 for its animations part and says users must be able to pause carousel movement. Success criterion 2.2.2 (Level A) has two parts that matter here:

• Moving, blinking or scrolling content that starts automatically, lasts more than five seconds and is presented in parallel with other content needs a mechanism to pause, stop or hide it, unless the movement is essential.
• Auto-updating content that starts automatically and is presented in parallel with other content needs a mechanism to pause, stop or hide it, or to control how often it updates, unless the updating is essential. There is no five-second exception.

W3C's explanation describes auto-updating content as content that updates or disappears based on a preset time interval, and lists "auto-advancing presentations and messages" among its examples. In GotAlt's reading, a carousel that swaps slides on a timer is that kind of content, and a carousel on a page with other content is presented in parallel with it. A carousel that moves only when someone activates next or previous does not start automatically: W3C says that phrase covers updates that are not the direct result of a user's intentional activation, such as selecting a button. So 2.2.2 does not apply to it, though the rest of this guide does.

What counts as a mechanism

• A button is the usual answer. W3C says "pause" is meant in the sense of a pause button, though other mechanisms can be used, and lists technique G186, a control that stops moving or auto-updating content, among the sufficient techniques.
• Pausing only while focus is on it is not enough. W3C says an animation that stops only while the user has focus on it, then restarts when focus moves away, would not count as a mechanism. In GotAlt's reading, a pause that lasts only while the pointer hovers is no better. Add a button even if you also pause on hover and focus, as described below.
• Reduced motion. The prefers-reduced-motion media feature, documented by MDN, detects a device setting to minimize non-essential motion. Not starting rotation when it is set is a good default, but in GotAlt's reading it does not replace the button, because not every visitor has the setting on. See animation and reduced motion.

Structure and names

The tutorial recommends marking slides up as a list, or other fitting elements, inside a labeled region. The APG adds that the container has role region or group (the APG says which depends on the page; see our landmarks guide) and aria-roledescription set to carousel. Each slide is a group with aria-roledescription set to slide, and a name. Because that property supplies the words "carousel" and "slide", labels should not repeat them. With no unique slide names, the APG accepts a number and set size such as "3 of 10".

<section aria-roledescription="carousel" aria-label="Featured offers">
  <button type="button">Stop slide rotation</button>
  <button type="button">Previous slide</button>
  <button type="button">Next slide</button>
  <div aria-live="off" aria-atomic="false">
    <div role="group" aria-roledescription="slide" aria-label="1 of 3">
      <img src="boot.jpg" alt="Brown leather hiking boot with red laces">
      <a href="/boots/">Shop hiking boots</a>
    </div>
    <div role="group" aria-roledescription="slide" aria-label="2 of 3" hidden>
      ...
    </div>
  </div>
</section>

This sketch follows the APG's description of a basic carousel that rotates automatically; the labels are examples. The live region is off while it rotates, and script should change it to polite once rotation stops. Slides that are not showing carry the hidden attribute, and MDN's hidden attribute reference notes that setting a CSS display value on a hidden element overrides it, so check your slide styles.

Controls: rotation, previous, next and slide pickers

• Use native, named buttons. The tutorial says button elements give semantics, assistive technology support and consistent keyboard behavior, and the APG recommends them (see buttons and links). An arrow icon with no text alternative leaves a button with no name, which our rule checks map to 4.1.2; the tutorial gives its arrow images alt text such as "Previous Item".
• Make the rotation button say what it will do. The APG labels it "Stop slide rotation" while rotating and "Start slide rotation" while stopped, with no aria-pressed, and makes it the first Tab stop in the carousel. The tutorial adds that script should change only the button's content, because replacing the button loses keyboard focus. Per the APG, activating rotation, next or previous does not move focus.
• Stop on hover and focus. The APG stops rotation while the pointer is over the carousel and when keyboard focus enters it, and does not restart unless the user asks. The tutorial restarts when the pointer or focus leaves. In GotAlt's reading the APG way is the safer default, because it never starts moving again under someone who is still reading.

Slide pickers: dots, tabs and numbers

The APG describes three carousel styles and says which costs keyboard users the most.

Name each picker by its slide or number, and show the current one by more than color: the tutorial adds visually hidden text such as "(Current Slide)" and a different shape. The tabbed style follows the tabs pattern; see accessible accordions and tabs.

Announcing slides, managing focus and hiding the rest

The APG gives the reason. If slides rotate unnoticed, a screen reader user may read an element on slide 1, ask for the next element and hear one from slide 2, with no sign that the context changed. Three practices prevent that:

• A live region, used with care. The tutorial adds a visually hidden polite live region and, when someone uses previous or next, sets its text to "Item x of y". The APG makes the live region optional and sets aria-live to off while the carousel rotates and polite when it does not. In GotAlt's reading, announce only changes the user asked for.
• Focus stays put. The tutorial says an automatically advancing carousel should not draw users away from their place. When someone picks a slide with a numbered button, it moves focus to that slide, which needs tabindex="-1".
• Hidden means hidden. The APG warns that slides incorrectly hidden, for example displayed off-screen, confuse screen reader users, and MDN says content with the hidden attribute is hidden from all presentations. Do not leave aria-hidden on anything that can take focus: our free scan flags it as a 4.1.2 problem (see aria-hidden and focus).

See ARIA basics for the vocabulary and how screen readers read a page for the result.

Touch, swipe and small controls

Success criterion 2.1.1 Keyboard asks that all functionality work through a keyboard interface. Pointer and touch use is a separate matter:

• Do not rely on dragging. Success criterion 2.5.7 Dragging Movements (Level AA, new in WCAG 2.2) asks that anything operated by dragging can also be done by a single pointer without dragging. W3C's example is a draggable news carousel with forward and back buttons. The alternative cannot rest only on swiping, and keyboard support is judged separately.
• Size the controls. Success criterion 2.5.8 Target Size (Minimum) (Level AA) asks for pointer targets of at least 24 by 24 CSS pixels, with exceptions that include enough spacing around smaller targets and an equivalent control on the page that meets the size. The tutorial recommends at least 44 by 44 for buttons and links that are not inline in text. Measure the slide-picker dots first; see touch target size.
• Keep controls visible and readable. Focus must be visible (focus indicators), and dots or arrows over a photo need contrast against what is behind them (non-text contrast).

The slides themselves

• Images need a text alternative. WCAG 1.1.1 asks for a text alternative that serves the same purpose, and purely decorative images must be hidden from assistive technology, usually with an empty alt (see decorative images and the alt text guide). If a promotion lives in the picture, put its message in the alt text, and in real text where possible: images of text.
• Prefer real text over a background image. The tutorial's richer example puts an article with a real heading and paragraph on a slide's background image; for readability, see text over images.
• Make link text stand alone. Slides that all say "Shop now" are links no one can tell apart; see accessible link text.

Sliders that choose a value

"Slider" also names a control that picks a value along a track, such as a price filter. Build it with a native input of type range and a visible label. MDN says the control is imprecise and suits only values where the exact number does not matter. If it does, add a text input beside it, which W3C's explanation of 2.5.7 accepts as a single-pointer alternative to dragging. See accessible forms for labels.

Check it yourself

Most of the tests that matter for a carousel need a person. Try these on each distinct carousel:

1. Leave the page alone. Does anything move on its own? Is there a visible pause button, and is it the first Tab stop in the carousel?
2. Tab in. As the APG describes, rotation should stop when focus enters and stay stopped until you use the rotation button, and it should pause while the pointer is over the carousel. Focus should always be visible and never land on something you cannot see. Our keyboard accessibility test has the full routine.
3. Press Enter or Space on every control. Rotation, previous and next should work and keep focus on themselves, and the picker should show the current slide.
4. Listen and use a phone. With a screen reader on, the carousel should be announced with its name, next and previous should say which slide you reached, and automatic changes should be silent. On a phone, every function should work with taps, not only swipes.
5. Run the accessibility bookmarklet on the rendered page. It reports images with no alt attribute, buttons and links with no accessible name, and the contrast of text it can measure. It does not press keys and reads the page as it is when you click, so run it again on another slide.
6. Judge the images. The alt text checker says whether alt text is true of its image, and the image contrast checker measures text over a photo.
7. Scan my site for free to run 16 rule-based checks on up to 3 pages, including missing alt attributes, buttons and links with no accessible name and aria-hidden on a focusable element. They press no keys and cannot see a timer script.

Passing these is a good sign, not proof that a carousel meets WCAG. The guide to making a website accessible puts the check in context.

Keep it checked

A carousel plugin update, a new campaign slide or a changed theme can break any of the above after your last review. GotAlt checks the pages you monitor every week. It compares each image's alt text with the image itself (up to six images per page), runs its rule checks, opens monitored pages in a browser for contrast and other render-dependent checks (see what we check), and reports what changed. Plans are from $69 a month. Audit my whole site from $69/mo.