Accessibility by Default: Carousels
Hi, and welcome back to Accessibility by Default. If you’re new here, welcome in, and if you’re a returning reader, thank you so much for coming back. This week we’re going to be looking at the implementation of the carousel component.
Don’t implement it. Just don’t do it. It’s an accessibility nightmare and will cause more headache and frustration for you than what it’s worth.
The end.
Thanks for stopping by. See you next week!
Why are you still here? There’s nothing else, no more than that.
Ok fine, right, let’s just talk about it, because if you really really have to implement one, you’ll have to do it correctly.
What is a carousel?
A carousel is a collection of related pieces of content, often referred to as slides, that users can move through one at a time. These might contain things like images, text, cards or other content.
Users can move through the different items using controls such as previous and next buttons, pagination indicators or other interaction methods.
A carousel isn’t directly inaccessible, just a badly implemented carousel is.
When should you use it?
You shouldn’t. Don’t.
Ok, sorry, I’ll stop making that joke now.
Carousels can be useful when you have a collection of related content that you want to present in a limited amount of space. For example, you might have a set of related promotional cards or a gallery of images where displaying everything at once would take up a significant amount of space.
But just because you can put something in a carousel doesn’t mean you should.
Before reaching for a carousel, ask yourself whether hiding some of the content behind previous and next controls actually improves the experience for the user.
If the content is important, would it be better to show everything at once?
If the user needs to compare several items, would a grid or list be easier?
If the content is constantly changing, is automatic rotation actually helping the user, or is it just making things harder to follow?
A carousel should be used because it genuinely improves the user experience, not simply because someone decided that there wasn’t enough room on the page.
Accessibility considerations
Don’t automatically rotate content
I think that this is the main one when we’re looking at the accessibility behind carousels.
If the carousel is going to automatically move through the slides then you need to give the users a way to pause or stop it. I’ve seen so many carousels that automatically rotate and, to me, that’s annoying. There have been so many times that I haven’t even processed the information before it’s automatically moved on. And if the user is trying to interact with something on the current slide but then it suddenly changes, that isn’t going to be a great user experience either.
Give users control
If you must implement a carousel, then the users should be able to navigate through it manually. The previous and next controls should be keyboard accessible and they should have clear accessible names. “Previous slide” and “Next slide” are going to be much more useful to screen reader users than just using “Previous” and “Next”. Screen reader users need to have additional context for what the buttons are going to achieve.
Get Josh Allan’s stories in your inbox
Join Medium for free to get updates from this writer.
And, if you’re going to use pagination indicators, the current slide should also be communicated to the user.
Keyboard interaction
As always, a user shouldn’t need a mouse or touchscreen to use the component.
Every interactive control within the carousel needs to be keyboard accessible, and the user should be able to move through the carousel without getting trapped inside it.
If the carousel contains links or buttons within each slide, those need to be reachable in the expected tab order too. If a slide contains multiple tabbable elements, tabbing past the last one should move focus on to the next control in the carousel, such as the “next slide” button, rather than looping back to the start of the same slide, and rather than jumping the user out to unrelated content elsewhere on the page.
Focus management
This. Now this is where the fun begins.
When the carousel slide changes, you shouldn’t start throwing the focus around willy nilly. If a user is interacting with the carousel and then we move the focus to somewhere else every time the slide changes, that experience is going to be so bad for the user.
Focus should generally remain where the user expects it to be, and changing the visible slide shouldn’t unexpectedly steal focus from the user.
Make the current slide clear
The user needs to know which slide they’re currently on, especially if you have several.
For example, if you have five slides, someone using a screen reader should be able to know that they’re currently looking at slide 2 of 5.
We also need to make sure that the content from the inactive slides isn’t being exposed in a way that makes the experience confusing. If a slide is no longer active, we need to consider whether the content should still be available to assistive technology.
This is one of those areas where adding aria-hidden="true" can cause problems. If the slide contains focusable content, we need to make sure we're not hiding something from assistive technology while still allowing keyboard users to reach it.
Don’t forget reduced motion
If the carousel uses animations or transitions when moving between slides, we should respect the user’s reduced-motion preference.
CSS gives us a way to detect this with prefers-reduced-motion, allowing us to reduce or remove animations for users who have requested less motion.
There’s not much point in making our carousel technically accessible if we’re then making someone feel like they’re on a fairground ride whenever the slide moves.
Touch and swipe
A lot of carousels rely on swiping on mobile devices, but we shouldn’t make that the only way to navigate them.
Touch users should still have access to clear controls, and any swipe interaction should work alongside the other methods of navigation rather than replacing them.
Something to keep in mind is the conflict between swipe gestures and screen reader navigation. Both VoiceOver and TalkBack use swipe gestures to move between elements on a page, which can clash with a carousel’s own swipe to change slide behaviour. It’s usually best to provide visible on-screen buttons as an alternative, and make sure they’re not too small or easily missed because if users can’t find them, they can’t use them.
Final Thoughts
Carousels aren’t inherently inaccessible. They can be made accessible, but they do introduce a lot of additional things to think about that you might not need to think about if you were to use something else like a list, a grid or just showing all of the content.
So, before you start building one, just stop and ask yourself whether you actually need it and whether the trauma is going to be worth it.
If you do, then make sure you’re thinking about how it works for everyone, not just how it looks when someone clicks through it with a mouse.
And if you don’t need to use one?
Smile and be happy.
Accessibility by Default is a series where I explore practical accessibility techniques from the perspective of a frontend engineer. Rather than repeating specifications, the goal is to explain the engineering decisions and patterns that make accessible interfaces easier to build from the start.
You can find the full series on my profile
