Accessibility expert and WebAIM associate director Jared Smith has warned us all to stop using carousels. His warning comes in the form of microsite Should I Use A Carousel?, which - in carousel format - provides reasoning for not using this kind of interface component. Along with posing accessibility issues for keyboard and screen readers, industry figures quoted on the site argue carousels are poor from an engagement standpoint.
Smith (JS) spoke to .net about the reasoning behind the site, and why carousels should be avoided.
.net: What was the thinking behind the site?
JS: I created shouldiuseacarousel.com on a whim. WebAIM provides web accessibility consulting, and I was preparing for a webcast for higher education institutions on keyboard accessibility. As I researched carousels, I decided at the last minute to write a carousel to share my findings and demonstrate carousel usability issues in a way that would educate, entertain, and cause folks to realise, "Hey, these things really are frustrating”. I spent less than an hour building the site and $10 for the domain!
.net: What has the reception been to the site?
JS: On Tuesday afternoon I tweeted the URL. I woke up the next morning to 214 text messages and about a thousand Twitter alerts! I spent the next few hours trying to keep our server from crashing under the traffic load and being amazed at the power of social media. The site has had well over 100,000 page views in 36 hours, but I’m mostly happy with the dialog and thought it has encouraged, especially in the web design community.
.net: Why do you think carousels have become so popular?
JS: I think carousels are popular because they're popular! They began on a few trendy sites, and so others followed. There has been little testing of them, and because they're dynamic, scripted elements, it's harder to measure their effectiveness and use. I admit carousels work adequately for finding content you already know is within the carousel, but they’re much less effective for end users to discover content they don't know about. Without end user testing, it's easy to overlook the issues your own carousels might cause.
.net: So why do people use them?
JS: Carousels are seemingly an easy fix to two universal design problems: how do I fit so much content into so little space, and how do I decide what content is the most important? It's easy to justify away the usability issues of a carousel when you consider the benefits of presenting multiple content pieces in such little real estate. This has been exacerbated by unfounded focus on above-the-fold design.
.net: If a client or boss argues you must place a carousel on the page, how should you argue against this? What would be a better thing to replace it with?
JS: In WebAIM's accessibility efforts, we've found demonstrating accessibility issues—such as listening to a page in a screen reader—is the best way to make people acutely aware of the end user impact. Demonstrating carousel usability and accessibility issues—or better, watching an actual end user experience them—will usually do the trick.
As for alternatives, I simply don't think there is a suitable interaction or widget that can replace carousels. Eradicating carousels will instead force better content and design decisions—what is the most important content and how can I present it in a meaningful, simple, and accessible way? If my site has caused some people to realise this, it has succeeded.
.net: You’ve mentioned carousels impacting on accessibility, but in what ways does this happen?
JS: Beyond usability frustrations caused by carousels for all users, there are several distinct issues for users with disabilities. For auto-playing carousels, having content automatically disappear can cause loss of focus for screen reader and keyboard users that are reading or have keyboard focus on that content when it animates away. This can force the user back to the top of the page.
There also is no easy way to semantically or programmatically associate the controls for a carousel—often just numbers or dots—with the carousel content. This is especially difficult for users that cannot see the interface. The cognitive load and distraction caused by carousels can be especially difficult for some users with cognitive and learning disabilities.
If, after all this, you decide to implement a carousel, we recommend not having it automatically advance. Give control of the content presentation to the user. If it does auto-advance, provide a pause link or button, and ensure that the carousel pauses if the user hovers their mouse over or sets keyboard focus to the carousel or its controls.
.net: Are there any other regularly used web design components you also think should be consigned to history?
JS: Beyond Flash and a few other things that are already consigned to history, it's very rare that we cannot come up with suitable accessible solutions to complex interactions. If you can justify the presentation and interaction, we can make it accessible, especially using the ARIA (Accessible Rich Internet Applications) specification.
Carousels are a rare exception because they combine so many usability, accessibility, and content issues for all users into one widget. Even if made technically accessible or compliant, functionally, the end user experience is unlikely to be a good one. And hopefully shouldiuseacarousel.com has prompted thought about this and other usability and accessibility concerns.
