Forem: Jason Webb

How to build a more accessible carousel or slider

Jason Webb — Tue, 25 May 2021 19:09:26 +0000

Carousels! They aren’t effective or popular with real users, and yet they can be found all over the web. Often the result of competing internal priorities, carousels might be thought of as a manifestation of unclear business goals or unresolved internal conflicts.

Regardless of why they are used, one thing is practically universal — carousels are almost always inaccessible to disabled users. In this article we’ll look at common accessibility barriers found in carousels, talk through some good solutions, and then connect you with some practical resources you can start using right now to make your carousels more accessible!

What is a carousel, anyway?

Those of us who design or build web experiences can usually spot a carousel from a mile (or kilometer) away. They are a region of the page that acts sort of like a slideshow, allowing users to move through a bunch of content that would normally not be possible to fit into that same amount of space.

Carousels vary quite a bit in their use cases, features, and implementations, which can make it pretty difficult to come up with a precise, universal definition. What we can do, though, is list out the most common characteristics they can have, such as:

May have one or more slides visible at a time.
May have slides that contain simple content (like a single image each) or complex content (like form fields and tooltips and all sorts of other complicated things).
May have controls to navigate to previous and next slides.
May have controls to jump to specific slides.
May automatically advance through slides all on its own, at whatever pace the owners felt like using.
May be oriented horizontally, vertically, or even in 3D!
May wrap its slides around when a user tries to move past the end or beginning of the set (sometimes called “infinite scrolling”).
May visually emphasize a single slide to show that it is “active”.

Common accessibility issues in carousels

Although carousels can vary quite a bit in their features and implementations, there are a few things that they consistently get wrong for accessibility. Through extensive live user testing with native screen reader and keyboard-only users at Accessible360 across hundreds of websites, we find the following issues over and over again:

Screen reader users very often don’t know when their virtual cursor enters or leaves a carousel, making it difficult for them to know that it even exists or how to get out of it.
Nearly every carousel is built differently (even if they look the same), so screen reader users can have a tough time building up a consistent mental model that makes carousels easier to navigate later on.
Many carousels do not hide their non-visible slides from all users, forcing keyboard and screen reader users to go through every single piece of content in them, even though mouse users don’t have to.
Semantic <button> tags are often not used for actionable elements like the previous, next, and slide dot controls, so keyboard and screen reader users often aren’t able to reach, understand, and activate them.
Inaccessible icons are often used, usually without human-readable accessible names, which can make controls unusable for screen reader and voice input users.
If the carousel automatically advances, keyboard and screen reader users can be constantly tossed around in the DOM, unable to make sense of the content that keeps shifting in front of them. Auto-rotation can also be very distracting and disruptive for people with cognitive conditions that affect their attention or memory.
Sometimes carousels come with hidden keyboard commands, like using the arrow keys to move between slides. But since carousel implementations are not really standardized, these commands will really just confuse real keyboard users, since there is really no reason to expect them to be there.

Key elements of an accessible carousel

At the moment, there is nothing in the HTML specification that really resembles a carousel, so defining how an accessible carousel “should” be built is tricky. The W3C’s WAI-ARIA Working Group has provided a design pattern in their WAI-ARIA Authoring Practices 1.1 guide with some good guidance, but the group has also published a tutorial with some different guidance, which tends to be a bit confusing if you aren’t deeply involved in the accessibility scene. (Hopefully this’ll improve, though! See issues #594 and #1167)

At Accessible360, our team of expert accessibility auditors, which includes native screen reader, keyboard, and other AT users, has been carefully crafting and iteratively refining a practical approach to carousels that we use to guide our clients towards WCAG conformance in a clear, consistent way. The approach that we’ve developed has a lot in common with this example from the WAI-ARIA Authoring Practices design pattern, and uses the following criteria:

Use the <section> tag (or role="region") with a generic aria-label (like aria-label="hero carousel") for the wrapper element so screen reader users know exactly where the carousel starts and ends in the DOM.
Add simple instructions for screen reader users to explain how the carousel is set up and how it works. This isn’t required for WCAG conformance, but until carousels become more standardized, instructions can help screen reader users build up a useful mental model.
When a slide is not visible on the screen, it should be hidden from all users either using CSS (like display: none or visibility: hidden), the HTML hidden attribute, or by adding aria-hidden="true" to the slide’s wrapper and tabindex="-1" to all the focusable elements inside it. FYI — that last technique is the most animation-friendly.
Avoid using list markup for the slides. Screen readers announce how many list items are in each list, but ignores list items that are hidden. If you are truly hiding the slides that aren’t visible (see previous point), then the number of list items announced to a user won’t match the true number of slides. Also, most screen readers don’t tell users which list item they are currently on, or when they enter or exit one (the next point will cover that!), so this markup isn’t especially useful in this use case.
Use role="group" and a numbered aria-label (like aria-label="slide 1 of 8") on the wrapper of each individual slide so screen reader users can easily tell where each slide begins and ends and where they are in the set.
Use semantic button elements with clear accessible names for all interactive controls, like the previous/next buttons and slide navigation dots.
Use aria-current="true" on the button of the slide dot corresponding to the currently-active slide so that screen reader users are informed.
Don’t use custom keyboard controls, like arrow keys for navigation. These just confuse real keyboard users, and are probably going to be missed entirely by screen reader users since they already use their arrow keys for navigating with their virtual cursor.
Disable autoplay — nobody actually likes it, and for some users this can be an absolute blocker! If you’re not in a position to say “no”, then you can at least minimize the harm by adding a pause or stop button to meet WCAG 2.2.2. But keep in mind, just because something conforms to WCAG doesn’t mean people will actually enjoy using it!

Try it out for yourself!

If you’re like me, nothing beats a live code sample to help really understand a complex component like this. So let’s take a look at what a “good” and “bad” carousel could actually look like, and do a little testing to see how each problem can resolved with the solutions above.

❌ Bad carousel

In this carousel, Murphy’s Law has taken over! Using the criteria above, see if you can spot all the things that are wrong with this. Be sure to use your keyboard and a screen reader, like NVDA or VoiceOver! Here are a few prompts to guide you:

Can you tell when you enter the carousel and when you leave it using a screen reader?
Can you reach all the controls with your keyboard?
Are you able to figure out what each control does based on what your screen reader says?
Can you reach content in the slides that are supposed to be hidden?
Can you tell which slide you are on using only your screen reader?

✔️ Good carousel

Now let’s take a look at a carousel that looks and feels exactly the same, but uses more accessible code. Compare it to the “bad carousel” example above, and be sure to also use your keyboard and a screen reader to experience it in different ways!

Accessible boilerplates for common carousel packages

Knowing what makes a carousel “good” or “bad” for accessibility is all well and good, but actually putting that knowledge into practice in the real world might be easier said than done!

In the real world, most of us devs use third-party, open source packages like Slick Slider or Flickity whenever we need a carousel, which adds another layer of complexity that makes it even harder to deliver accessible experiences. Unfortunately, many of these packages have either been abandoned or have communities that are so large and ad-hoc that forward progress is a real challenge.

Luckily, most of these packages provide APIs that you can use to make adjustments for accessibility at specific times, like adding ARIA attributes or using custom elements for controls. But since each API and package is a little bit different, it takes time to read through the developer docs and figure it all out.

Wouldn’t it be great if there was a repository of ready-to-go code snippets for popular carousel packages that you could drop into your project to make them more accessible and save you some time? Well, we thought so too, which is why we’ve been building out a set of consistent code samples for common use cases that you can start using right now! You can get these samples at either of the following places (the samples are the same!):

Github repo: https://github.com/Accessible360/accessible-carousel-boilerplates
CodePen collection: https://codepen.io/collection/narjZO

There you’ll find realistic code snippets for hero banners, linked product cards, tiles with quick view popups, and even PDP product images with a carousel of thumbnails. So far, code snippets have been created for accessible-slick, Flickity, Owl Carousel 2, Slick Slider, and Splide. To request snippets for other packages or use cases, feel free to open an issue on the Github repo!

Here is just one of these examples, which uses accessible-slick (a highly accessible Slick Slider fork built by Accessible360) to implement a responsive product tile slider with “quick view” modal dialogs:

Credits

The research and code snippets in this article are provided by Accessible360, whose expert accessibility engineers were invaluable with their insight, feedback, and time on this topic.

If your company is looking for an accessibility partner to help bring your product to the next level through live user audits, monitoring, training, or remediation support, then get in touch today!

Sources

Auto-Forwarding Carousels and Accordions Annoy Users and Reduce Visibility by Jakob Nielsen via Nielsen Norman Group
Carousel Usability: Designing an Effective UI for Websites with Content Overload by Kara Pernice via Nielsen Norman Group
ShouldIUseACarousel.com by Jared Smith
Accessibility expert warns: stop using carousels. Interview with Jared Smith by Creative Bloq
The Unbearable Inaccessibility of Slideshows by Gian Wild
Carousel Interaction Stats by Erik Runyon

How I built an accessible IoT dashboard

Jason Webb — Sun, 02 Feb 2020 16:15:41 +0000

The IoT has incredible potential for changing the way we interact with the world around us. We all know that it’s a game-changer for home automation, sensor data acquisition/management, and industrial applications, but what about for the people using these systems?

When you think about it, the IoT is not just about building devices that communicate at a distance — it’s also about creating digital interfaces to the world around us. When built well, these interfaces can be used by anybody to interact remotely with objects that they may not be able to otherwise.

We hear a lot about the business and technical reasons why remote monitoring and management are helpful — maybe the devices are too far away, or in an extreme environment, or there are simply too many to keep track of any other way. But as it turns out, there are also all sorts of human reasons for remote access too!

Consider someone with low or no vision who wants to check their mailbox for mail, or find out how much time is left for a load of laundry, or see if their oven has reached a set temperature. While they more than likely have adaptive strategies for performing these tasks, those are usually very time-consuming and tedious. Imagine how much easier it would be if they could find out all of this information in just a matter of minutes using a web interface!

These situations are more common than you might realize. Nearly 1 in 5 people in the US experience some form of disability, and nearly everyone has experienced (or knows someone who has) temporary or situational impairments that make it hard to use our favorite “things” and digital interfaces. May you’ve experienced nausea or vertigo while recovering from a medical procedure, or needed to find answers fast during an emergency situation, or even just run out of power on your wireless mouse!

When we build accessible web interfaces we aren’t just tacking on specialized features for edge cases — we’re creating clean, intuitive experiences that we can all understand and use more easily with whatever devices, inputs, and skills are available to us!

A Dashboard for Everybody!

So what would a clean, intuitive, and accessible interface for an IoT project look like? As part of IoT Hack Day 2019, a full-day hackathon in Saint Paul, MN, I captained a team to create a speculative sample dashboard to demonstrate some design and development techniques that any IoT interface can use, which I hope helps answer that question.

In this article, we’ll dive into some of the most important accessibility features and techniques used in the dashboard, but if you’d like to dive right in you can play with it right now using randomized mock data here:

https://jasonwebb.github.io/dashboard-for-everybody/dashboard

Get the source code!

All of the code for this project is available for free over on Github under the MIT license. This means that you are completely free to use it, remix it, and integrate it into your project (even commercially).

Just keep in mind that it was built as part of a hackathon, and is mainly meant to be an educational resource and a proof-of-concept, not a production-ready package 😄

jasonwebb / dashboard-for-everybody

Demo project of a real-time data dashboard showing effective design and dev techniques for making complex interfaces accessible for people with disabilities

And be sure to check out this sweet one-page documentation too: https://jasonwebb.github.io/dashboard-for-everybody/

Overview of accessibility features

A number of design and code techniques are used to make the dashboard experience easy and intuitive for most people, all based on the four guiding principles of the Web Content Accessibility Guidelines (WCAG).

Simply put, these principles (POUR) define four high-level criteria for how content on the web should be built to be considered accessible. All content should be perceivable, operable, understandable, and robust for all users using the tools and abilities available to them.

The main techniques and features that were implemented to meet these criteria include:

Fully operable via keyboard using native elements as much as possible.
Chart data is available to people using screen readers through visually-hidden tables.
Semantic, valid HTML is used extensively to provide a great user experience for people using screen readers to navigate.
Important asynchronous information (like the availability of input and output devices) is announced through live regions.
All focusable and interactive elements have strong, consistent focus indicators.
All panels have headings, even if they are visually hidden, so that people using screen readers can traverse the page quickly and easily.
Conforms to WCAG 2.0 (level AA) guidance.
Works great on mobile devices and tablets, which are very popular among people with mobility and visual conditions.
The display of live data can be paused or slowed down so that people using screen readers or with cognitive conditions (like dyslexia) can take all the time they need.

Automated scan reports

Although woefully imperfect, automated scanning tools can be used to get a very basic sense of accessibility and check for the most obvious of issues like invalid or inappropriate markup usage and (some) color contrast errors.

Automated tools do not, and arguably cannot, identify critical usability problems like how easy or pleasant your site is to use for people with disabilities. They are also not good at testing dynamic content or interaction states, or for checking for important best practices like the all-important “No ARIA is better than Bad ARIA” principle.

So use them, but don’t rely on them! Just because a page has a perfect audit score doesn’t mean it’s fully and perfectly accessible — it just means that some of the most obvious problems seem to be resolved.

For example, this dashboard passes all the major scanning tool with perfect scores (see the screenshots below), but there is almost certainly work to be done to improve overall user experience!

Accessibility techniques used

Now let’s take a closer look at the most important and helpful techniques used to make the dashboard accessible:

Focus indication

When designing and building any web project, don’t forget about the humble focus state! Great focus indicators make a world of difference for keyboard-only users and are absolutely essential for people with low vision (see WCAG S.C. 2.4.7).

Let’s be real. The default focus indicators provided by browsers are not always very effective or attractive, especially when different foreground and background colors or background images or videos are used. As a result, it's not uncommon for popular design frameworks, style resets, and normalizers to remove them entirely — not cool! If you’re going to remove the browser’s default focus indicators, you should provide an even better one!

In the sample dashboard project, the following techniques are used to improve focus indication for all users:

Strong, consistent focus rings are added around all interactive elements, like buttons and input fields.
Label text next to radio buttons change colors and gets bolder to make it extra clear when they receive focus.
Panels (the white container boxes) get a stronger border when something inside of them receives focus. This is not really necessary, but I thought it might be helpful to subtly draw the eye to the general region of the page that is “active” — this is probably more speculative than functional.

Making charts accessible

Charts are notoriously difficult to make accessible, but there are a couple of effective strategies that can be used in nearly every situation.

First, take a good look at your chart and really think about whether all the features being used actually improve understanding for most users. Your charting library probably provides all sorts of cool, interactive doo-dads like hoverable content, animations, and quirky chart types — but how many of them are really facilitating a better understanding of the data, and how many are just fun to play with? Simpler charts are easier to grok for everyone — remember the KISS principle!

Second, remember that every chart is ultimately a visualization of tabular data. There may be a lot of data, and it may be spread across multiple sets and sources, but at the end of the day its all just a bunch of rows and columns. This is exactly what good old HTML <table>s are meant for, and they actually come with some really neat functionality for people using screen users! So rather than trying to make the charts themselves accessible (which may not be possible depending on the charting library), consider providing the same data in a visually-hidden table and hiding the visual chart using aria-hidden="true".

A word of caution, though: if your chart includes necessary custom keyboard or mouse functionality (like tooltips), a visually-hidden table won’t help keyboard-only users who have vision. Again, ask yourself, “Is this functionality really necessary?” If so, provide an alternative and obvious mechanism that can be used to activate that same functionality using only the keyboard.

Working with live data

Fast-moving live data, especially when it comes from real-time devices, can be overwhelming for people with certain visual or cognitive conditions. Many times we can’t slow down the actual data streams, but we can provide some control over how quickly this data is displayed in the UI.

In this dashboard we provide two mechanisms to help people control the rate of change of the UI for easier processing:

Users can pause or resume the display of live data using a large, clearly-labeled button
Users can choose the update interval of the UI using a dropdown, giving them more time between updates to process the changes.

Announcing important asynchronous events using live regions

When working with real-world systems, sometimes things happen that disrupt the “normal” user flow — servers go down, devices go offline, connections degrade or get throttled, and so on. For visual users, dashboards are fantastic for monitoring the status of many sub-systems all at once, but what about people who rely on inherently linear tools like screen readers?

When asynchronous events happen, the importance of the event is usually indicated by the “severity” of the notification. Minor events might just cause a change in a color or a word somewhere, whereas major events might trigger a prompt, an audio cue, or some sort of big, scary visual indication that draws the eye.

For people using screen readers, minor events can be indicated using clear changes in the text, which they will find organically as they traverse the page. Sometimes it’s tempting to keep this text visually-hidden while only display a change of color or shape for visual users, but this is not the best solution given how important visual text is for people with limited vision (like colorblindness) and people with cognitive conditions.

Major, disruptive events (like a device going offline) may be indicated to screen readers using ARIA live regions. These are DOM elements that have been marked in such a way that tells screen readers to “watch” for changes that occur to their inner content and be ready to read those changes out when they happen. This technique should be used very sparingly because it can interrupt and even surprise screen reader users as they are going about their business. But if the event is important enough, they’d rather be surprised when it happens than be frustrated when they realize the form they just filled out is pointless!

Live regions and how they are experienced are much easier to understand when you actually, well, experience them. This short demo video from Udacity does a good job of showing both how live regions are created, and how they are experienced through a screen reader:

Making dynamic UI updates

Not all changes to the UI need to interrupt the user flow. Often context and good content practices are enough to indicate to screen reader users that something is about to happen or can happen, and no special coding is required to guide users along.

For example, at the bottom of the dashboard users can set up “triggers”, which are simple conditionals that initiate pre-defined actions based on events in the data stream (“if [this] happens, then do [that] …”). When the user activates the “Add trigger” button, a UI change occurs in another part of the DOM — should this be announced to the users somehow?

As it turns out, screen reader announcements are not necessary in this case because of the abundance of contextual clues in this part of the page. First, the panel on the left with the form has the heading “Create a new trigger”, clearly indicating that the content that follows is used to do something.

Secondly, the action button itself has a clear label (“Add trigger”) that reaffirms the purpose of the form and sets an expectation that a trigger will be added when it’s activated. A generic label like “Submit” or “Add” would be less helpful for “low confidence” users who may reach the button and wonder, “Is this the right button?”

When any user activates the “Add trigger” button they have an expectation that one of two things will happen: either a trigger is added successfully, or there is an error. If successful, a trigger is added to the placeholder area, which is the next immediate element in the DOM. For people using screen readers, this means they will encounter it the moment they move past the “Add trigger” button.

By preselecting radio buttons and defining a default threshold value (displayed as a placeholder), its actually not possible to submit the form with errors. But if it were, we’d want to associate descriptive, visible error messages with each invalid field (using aria-describedy), then programmatically set focus on the first field with an error that people using screen readers don’t have to “figure out” where the problem is on their own.

Conclusion

If you’re building an IoT dashboard or some other real-time web interface, I hope this article has given you some practical tips for improving its accessibility.

To sum it all up, the most important takeaways I’d like to leave you with are:

Every interactive element needs a focus indicator, and what is provided by browsers by default it not always the best.
Make those charts accessible by simplifying interactivity and providing the data through visually-hidden tables.
Let users slow down the refresh rate for live data so they can take more time to process it.
Announce major events (like devices going online/offline) using ARIA live regions — but only sparingly!
Use semantic, valid markup as much as possible — nearly every semantic tag means another bit of “free” functionality for people using screen readers!

And finally, when building out an accessible web project of any kind, nothing beats having it looked at by real, live users! Not only can this sort of feedback provide your team with personalized insights and guidance, but it is also essential in minimizing risk and defending against legal action. Reaching out to an accessibility consulting company like Accessible360 (where I work as a Developer Advocate) is always a great idea!