Status: This is not ready for detailed review. It is an in-progress, unapproved editor’s draft.
- What to do: Ensure that all slide progression controls can be operated and understood by all users.
- Why: Some Users may be unable to use a mouse, while others may be unable to see the visual clues to identify the relationship between the current slide and its position in a list of slide controls.
- How: Ensure that controls can be activated by both keyboard and mouse, be distinguished from one another and that the current slide and focus state of slides is identifiable both visually and by screen readers.
- Conformance: Required to meet SC 1.3.1 Info and Relationships, SC 2.1.1 Keyboard, SC 2.4.7 Focus Visible and SC 4.1.2 Name, Role, Value.
Carousels may simply have “Previous” and “Next” buttons to enable users to progress through slides one at a time, a list of slide buttons so that the user can select which slide to view, or may have both types of control. For information on ensuring that they can be activated by both keyboard and mouse, see pages on keyboard control.
This should probably be in the Forms Tutorial
All of the slide progression controls need to be buttons, not links, as they perform an action on the same page rather than open a different web page.
If implementing a carousel from a script library that marks up the controls as links, you can use the WAI-ARI
role attribute (
role="button"), to make the links are recognized as buttons by assistive technologies.
Applying the WAI-ARIA button
role attribute to a link:
Previous and Next buttons
Images of left and right arrows are most commonly used to visually distinguish between “Previous” and “Next” buttons,these need appropriate
alt text for these two images is “Previous product” and “Next product”. Although only “Previous” and “Next” are essential as
alt attribute values, it is good practice to provide the extra context to help users understand that they are still within the products carousel.
Slide list buttons
When a list of slide specific buttons are provided, they convey a variety of information, such as identifying how many slides are available, distinguishing between inactive slides, the current slide and whether or not a slide button is in tab focus. All of this information needs to be conveyed both visually and in a way that screen readers can recognize.
Visually the above controls show four numbered buttons, The current slide button (number 2) is larger and in the reverse colour combination to the others, button 4 has an additional outline to show that it is the control currently in tab focus, (if activated it would display slide 4).
To convey the same quality of information to users who can’t see the screen, the controls need to be marked up as a list, (screen readers can then inform users of the number of items in the list),and the current slide needs to be identified. Accurate labelling of the buttons will let the user know which control has focus.
The script should be capable of identifying the current slide and rendering its identification within the text or text alternative for the current button.
Note: The buttons in the above image are numbered which is important for speech recognition software users. Unless each button has a visible label, these users cannot know what command to give their software to navigate to the desired slide.
Where the generated code creates text links that the script then renders as images: