If you must use a carousel, make it accessible
This article is part of an ongoing series of accessibility tips for experience designers. It discusses how to design a carousel or slider that is accessible for people navigating the page with a keyboard.
What is a carousel or slider?
Some people call them carousels, some people call them sliders. A carousel or slider is a content display paradigm in which a list of related content items are presented in panels as a horizontal slideshow. The slideshow is usually navigated by “next” and “previous” arrow buttons. Usually each item has a graphic, some text, and an associated link. Carousels can have one or multiple panels in the viewable area. Here is an example of a carousel that has multiple panels in the viewable area.
Why am I writing an article about carousels?
Good question. I hate carousels. The carousel paradigm for displaying content exists for one reason only. It exists because groups fight for that coveted front and center position on a web site homepage. A carousel is one way to guarantee that each group’s content has an opportunity to have a turn in that spot. Studies show that users rarely interact with them.
However, they are also one of the most popular paradigms web designers use to display content. The groups I mentioned above like them a lot, for the reason I mentioned above. So, if we are going to persist in using carousels, let’s all learn to design them in an accessible way.
How do people use carousels?
Well, studies show that most people don’t use carousels. But we can consider three general personas who could use them:
- Sighted users who use a mouse pointing device
- Non-sighted users who use a screen reader and keyboard to navigate
- Sighted users who use a keyboard to navigate
There are a variety of other users we could consider, but let’s start with these three to create a baseline for accessibility. Let’s look at that example again, that shows a carousel with three panels in the visible area. Assume there are two sets of three panels, so six panels in all.
Carousels for sighted users (who use a mouse pointer)
Sighted users perceive carousel content as a series of panels usually navigated via arrow buttons. The main carousel accessibility consideration for sighted users is to not make it auto-play. If you must make the carousel auto-play, then you need to provide a pause or stop button. If you use a pause or stop button, place it before the carousel, and provide descriptive link text like, “Pause animated content.”
Employing navigation dots below the carousel are another great visual cue for sighted users. The number of dots represents the number of panel sets available to click through. An active state on the dot tells the user which panel they are currently viewing. The dots should be clickable for a person using a mouse, enabling them to skip to the last panel.
“Previous” and “next” arrows should have disabled states. The “previous” arrow should be disabled when the carousel is showing the first panel. The “next” arrow should be disabled when the carousel is showing the last panel. Alternatively, the carousel can “wrap”, meaning that the user can always go backward or forward using the arrow keys. (There is a caveat about this below for keyboard users, however).
Carousels for people who use a keyboard to navigate
Consider that non-sighted people do not need to know that you have collected content items for display in a carousel format. For a non-sighted person, the important interaction is that they can tab through each item. As they tab, relevant information should be included in the focused area so that they have context on each piece of content. Thanks to Jaimecortesf for pointing out in the comments that the carousel panels should be marked up as an unordered list.
As a person tabs through the site, they should naturally tab into panel 1 of the carousel (without needing to know it is a carousel panel). Ideally, the panel 1 link should wrap around all panel text. In that case, the screen reader will read all text: “Panel 1 title. Here is a panel description that lets someone know what this panel is about. Panel 1 call to action.” Note that for a non-sighted person, hearing only the link label may not be enough to give them context.
A sighted person navigating by keyboard will need a visible focus indicator. This is a box that appears around content that has keyboard focus. Designers can work with developers to control the appearance of the visible focus indicator.
If the person presses “return” or “enter” on their keyboard while the panel has focus, they will be navigated to the link on that panel. If they press the tab key, focus will be moved to the next panel. When focus is on the last panel in the set, tabbing again should bring the next set of panels into view. The same action should occur as though the person had clicked on the “next” arrow. Then the person can continue tabbing through that set of panels.
Once the person has tabbed through all the panel sets, focus should move to the next interactive element that follows the carousel. Note that for a keyboard user, the carousel cannot wrap. We do not want to trap the keyboard user in the carousel. They need to be able to tab past it.
Should the arrow buttons work for keyboard users?
Making the arrow keys work with the keyboard results in a cumbersome interaction for keyboard users. The problem is that for a keyboard user, if the focus is on the arrow keys, it is not on the panel content.
For a sighted keyboard user, they could potentially use the “next” arrow to cycle through the panels. But consider how the keyboard focus order would work in that case, looking again at our carousel diagram below.
- Focus on panel 1 content.
- Focus on panel 2 content.
- Focus on panel 3 content.
- Focus on “next” arrow.
- Pressing “return” or “Enter” moves the carousel to reveal the next set of panels.
- The person would need to “back-tab” off of the “next” arrow back onto the panel they are interested in, if they want to follow the link. This is awkward. Note that this functionality would not be accessible for a non-sighted user. The non-sighted user would hear “next,” the panel-set would move, and they would have no idea they needed to back-tab to get, say, the 4th panel content into focus.
The front end developer could try to manage the focus so that as soon as a user interacts with the next button, the focus automatically goes to the next panel after moving the carousel, but this, too, could be confusing and is in danger of becoming over-architected.
Hopefully I have convinced you that the arrow key functionality is a hinderance for keyboard users. If not, let me know in the comments section.
That’s not fair
The sighted person is not forced to use the carousel at all. They can click around the page wherever they want. Yet keyboard users are forced to navigate through the carousel in its entirety. That’s not fair.
It might seem like it is not a big deal for a simple carousel like the one in my example. But what about a larger carousel with lots of panels? They do exist, unfortunately.
Luckily there is a best practice to deal with allowing screen readers to bypass large blocks of content. In the case of a large carousel, a hidden “skip” link could appear on keyboard focus. For example, consider a product recommendations carousel. The link before the carousel could read, “Skip product recommendation carousel.” Alternatively, provide a heading above the carousel (and above each content section on the page) so that people are able to navigate via headings. Aria landmarks work well for this purpose, too, when implemented correctly.
What’s next?
Developers must be instructed on where to put these links and what the link label should be. User experience designers need to explain desired carousel keyboard functionality to developers as part of their documentation.
