Carousels Tutorial

Implement an accessible carousel widget by providing a robust structure and user control:

Structure: Use semantic structure for the carousel to support proper function of assistive technology.
Functionality: Add functionality to display and announce carousel items.
Animations: Add a transition animation between items and ensure users can stop and resume it.
Styling: Style the carousel to make sure it’s usable and readable by everyone.

See also the complete working example and full code of the example carousel.

What are carousels?

Carousels show a collection of items one at a time. They are also known as “slideshows” and “sliders”. Typical uses of carousels include scrolling news headlines, featured articles on home pages, and image galleries.

What makes a carousel accessible?

Users must be able to pause carousel movement because it can be too fast or distracting, making text hard to read.
All functionality, including navigating between carousel items, must be operable by keyboard.
Changes to carousel items must be communicated to all users, including screen reader users.
The keyboard position (“focus”) is managed in a reasonable and comprehensible fashion.

Note: Carousels are disputed from a usability perspective because their content can be hard to discover. Ensuring accessibility can also improve usability.

Why is this important?

Typically, carousels are prominently located and are used to provide navigation or show page content. Accessible carousels are essential for many website users including:

People using keyboard navigation and voice input software can navigate between individual items.
People using screen readers will understand which item is currently shown and how to navigate between items.
People who are distracted by movement can pause animations.
People who need more time to read can pause animations, providing them with sufficient time to read and understand carousel content.

Related WCAG resources

These tutorials provide best-practice guidance on implementing accessibility in different situations. This page combined the following WCAG success criteria and techniques from different conformance levels:

Success Criteria:

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. (Level A)
2.2.2 Pause, Stop, Hide: For moving, blinking, scrolling, or auto-updating information, all of the following are true:
- Moving, blinking, scrolling: For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential; and
- Auto-updating: For any auto-updating information that (1) starts automatically and (2) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it or to control the frequency of the update unless the auto-updating is part of an activity where it is essential.
(Level A)
4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)