The Ups and Downs of Carousel Accessibility

Cowritten by: Allen Tan and Dana Frayne

Today, the ACLU is involved in fight after fight for our civil liberties, from protecting detained immigrants at the border, bringing a case to the Supreme Court for someone fired for being trans, and organizing to give people back the right to vote. In the middle of all this, our team was tasked with the redesign of the homepage. What an existential challenge! How do we represent the breadth of legal, advocacy, and organizing work that the organization does across its myriad issue areas?

WHY A CAROUSEL

If you visit the new homepage today, you’ll find a carousel up at the top. We want your first impression to encompass that variety of wins and ongoing fights, and to let the public know that for much of the distressing news that they were seeing, the ACLU is out in front of it.

Instead of having to choose just one item, the carousel lets us feature a lot of topline info in a manageable way. We chose to borrow the interaction model and visual language of the Snapchat/Instagram Stories format (full-bleed imagery, auto-advancing, tap-to-advance, slowly-filling bars, etc) to let users move through the carousel easily.

THE ACCESSIBILITY CHALLENGES OF CAROUSELS

On the web, carousels are notorious for being inaccessible, so we didn’t take this choice lightly. There aren’t many good examples out there, but one reference we returned to many times was the carousel found on Microsoft’s accessibility site. Ultimately we made some different choices than their implementation but we took a lot from it.

The ACLU’s website has long strived to meet WCAG AA standards, through a combination of following best practices and conducting regular audits from external accessibility experts, but we felt that it was important to do more. There’s only so much you can know without access to people’s actual, lived experience.

Over the summer we hired Dana Frayne, who specializes in accessibility research, to set up a framework for us to work with and learn from people with visual impairments. We reached out to the accessibility community in NYC, and ended up partnering with the VISIONS Center for the Blind and the NYPL Braille and Talking Book Library (who both provide equipment and training). We worked with participants who had visual, cognitive, and motor disabilities through a combination of broad interviews and usability studies of prototypes we were building. After going through many, many rounds, we then worked with the accessibility experts at Center for Accessible Technology to audit and improve our code.

Something that we found helpful in a large project like this one was to break down the research into smaller, thematic studies (structure, navigation, and language):

WHAT IS A CAROUSEL EVEN

Within our carousel, each slide has a few pieces of information:

• A short, punchy slogan
• a description with more details
• a call to action button
• the image’s alt text

Since each slide just had so much stuff, we worried that creating a carbon-copy of the sighted user experience would create problems. What are the previous / next buttons really for? And what is a carousel even, anyway? If the point of the carousel was to show a bit of many areas of work, could this information be shown as a list of slogans?

(In the Microsoft example, their carousel eschews any previous/next controls altogether, instead preferring to show its contents as a list with everything revealed. But was that too much information to throw at someone at the start of the page? What if we showed them a little from each slide instead, and those who wanted to know more had a way to do that?)

Within the team, we used the analogy of a dresser, where each drawer is a slide in a carousel: it is a better experience for screen reader and keyboard users to:

• go through all content in each slide (option 1), or
• see only the top of one slide and allow them to decide if they want to go through each one in detail (option 2).

Option 1. Dresser with all drawers open

In this carousel, a user can use their keyboard to advance through each slide, including the slogan, description, call to action button and image description and a screen reader will read out every item.

Our assumptions:

• Users are less likely to miss any information
• This might be daunting, especially for users with mobility issues due to the quantity of items to go through

Option 2. Dresser with one open drawer

In this carousel, a user can use their keyboard to advance through the first slide, including the slogan, description, call to action button and image description and after that the screen reader will only read the slogans of slides 2–5.

Our assumptions:

• One slide that reveals all 4 items gives enough context for what the expect in the other slides
• Not showing all the items will make it easier to skim through the carousel faster

Note: We tested both versions in every session, but would switch up the orders because starting with a particular version may set expectations on what to expect in the subsequent version and bias the results.

WHAT WE LEARNED

Many of our participants said that option 1 was too long, repetitive, and overwhelming. Some of our blind participants thought that they were navigating through a long list and while thinking the carousel to be a list wasn’t a bad outcome, we didn’t want the carousel to be perceived as a long series of content. Participants preferred option 2 because it required less items to navigate through and expected all the same items to be in the other slides even though they weren’t “open.”

Navigation Semantics

Now that we had a better idea in how to display the slides, we did another round of testing to understand whether it’d be a better experience if the carousel was represented as a more traditional slideshow with previous and next buttons, or to use a combobox (or more commonly known as a dropdown). The combobox would show a dropdown menu of all the slides’ slogans, giving them a preview, and selecting an option would update the page with the rest of the content from that item.

While participants liked the combobox direction once they explored and understood what was happening, the previous/next buttons were more quickly understood because it was a commonly used convention. The combobox is most frequently used in the context of a form, so adapting it for this purpose was risky. It’s possible that providing controls in the form of tabs would have worked well for this direction, and is worth further exploration.

In the end we took the more standard route, by adding previous/next buttons. While we had worried that mimicking the sighted user experience too directly would not be helpful, we found that this was fine for users who are fully blind, and made more sense for people who are partially-sighted because what they heard through their screenreaders had a closer correspondence to what they could see on screen.

Auto-advance Accommodations

When you first come to the homepage carousel, the slides will advance automatically to reduce the effort required to read everything in the carousel. There are pitfalls to auto-advance, however, so we’ve added multiple ways to turn this off, both implicitly and explicitly:

• Implicit: anyone hovering over the call-to-action button will automatically have auto-advance turned off, to avoid having the target link change out to another slide.
• Implicit: anyone with the “Reduce motion” setting enabled on their device will automatically have auto-advance turned off. (Given the size of the slides being animated, this can have an effect on anyone with vestibular dysfunction — estimated to affect 69 million Americans.)
• Implicit: once someone starts moving through the page with keyboard controls, auto-advance is turned off. This may be a sighted user who’s just trying to get through content faster, or someone moving through content with their screenreader.
• Explicit: there is a button provided for anyone who wants to turn the default behavior off.

When auto-advance is turned off, previous/next buttons are added to control the carousel. (By default, we follow the Stories format of tapping to advance to the next slide.)

Additionally, we spent a lot of time observing how screen reader users navigate web pages using VoiceOver and Talkback, the two screenreaders provided on iOS and Android phones.

While we can disable auto-advance automatically on desktop, but on mobile we can’t rely on keyboard controls as a trigger. So for mobile screenreader users, the carousel will automatically change content — and this can be even worse for users who had set their screen reader on high speed because the screen reader was reading content faster than the set time of each advancing slide. The auto-advance can still be turned off, either implicitly if the user has “Reduce motion” enabled, or explicitly using the button, but we made two additional changes to make this less terrible:

• The call-to-action buttons repeat their corresponding slide’s slogan text, to ensure that users don’t follow a link to a different slide.
• While the previous/next buttons are visually hidden by default, they still appear within the screenreader flow — and interacting with those buttons will disable the auto-advance behavior.

We are continuing to look for ways to improve this for mobile users, so we welcome any feedback or suggestions in this area in particular.

The Baggage of Language

One of the findings we are saddened by is how low the bar is for visually-impaired user experiences. Carousels in particular are widely reviled within the accessibility community because so much can and does go wrong in careless implementations. Even the mention of the word carousel led to many of our participants immediately skipping it under the assumption that it would not work well for them. A major motivation for publishing a detailed write-up of our process is to try to improve this state of things on the web and provide another example to reference.

Another interesting finding: early versions included a “play/pause” button as the explicit control, which many participants thought was linked to video or audio content. This was reinforced for sighted or low-vision users when they saw an icon similar to what’s found on a video player. As a result, the majority of our participants preferred to bypass the play/pause button. We updated the button label and screenreader only text from “play/pause” to “Stop autoplaying slides” to give users a more accurate description of what this button did.

CONCLUSION

Working with users of assistive technology early in the process is invaluable. Best practices and audits have their place but we learned a lot by observing participants with a variety of ability and preferences. Just as with other forms of usability testing, people confronted with terrible user experiences will blame themselves and say that they will learn how to do it “right.” It’s important to hear their stories to understand that, at the very least, we shouldn’t allow our products to deteriorate people’s confidence in themselves. We don’t accept this in other parts of our industry and we should not accept it here.

Want to learn more about the technical details? Look forward to a blog post next week about this.