Animation and Carousels
Introduction
Animated elements excel at capturing and directing user attention. They also excel at distracting and frustrating users when used incorrectly. Nobody likes trying to read an article or fill out a form while half a dozen animated ads, blinking popups, or scrolling news tickers get in the way. For people with cognitive and learning disabilities, animation can make task completion difficult or even impossible.
Animation
Animated content includes anything that moves, blinks, scrolls, or updates on its own, such as animated carousels, "toast" popups, jiggling icons, or spontaneous dialog boxes. These distractions impact usability for all users, but are especially obstructive to people with cognitive and learning disabilities. For a person with ADHD (which includes over 8% of adolescents and over 4% of adults), even a small animated element can make it very difficult to focus or complete tasks. Animated elements can also present significant difficulty for users who need extra time to read the content, such as users with cognitive disabilities or low vision.
Users must have a keyboard- and mouse-accessible way to pause, stop, or hide automatically moving, blinking, or scrolling content (such as carousels, marquees, or animations) that lasts longer than five seconds and is presented in parallel with other content. This also includes automatically updating content like news tickers, chat messages, and so on.
The easiest and most accessible way to accomplish this is with a simple <button> element. The button should be placed next to the animated content. Once the animation is paused, it must stay paused until the user activates the button again. When the user activates the button again, the content should resume from the point where it was paused.
As a best practice, we recommend having animated elements be paused by default, especially if the operating system preferences have been set for reduced motion or disabling animations. Otherwise, users are forced to navigate to the controls of the animated elements and manually pause them each time they load or reload the page.
Carousels
Many animated elements take the form of auto-rotating carousels, which constantly rotate through slides. Carousels, also known as "sliders", became popular around 2005 due to their visual appeal and space efficiency. Unfortunately, carousels don't work well. In fact, most users ignore or avoid carousels, leading to a lot of missed content on the web.
Not all carousels animate automatically. Manually controlled carousels require user input to transition between slides, typically by activating "Previous Slide" and "Next Slide" carousel control buttons. This allows users to access the content at their own pace. Because they aren't animated, manually controlled carousels are simpler and more accessible than their auto-rotating counterparts.
However, both types of carousels are complex and can introduce significant accessibility barriers. We discourage the use of carousels.
If carousels are implemented, there are several accessibility considerations in order for them to meet WCAG standards.
Accessibility Requirements
Both auto-rotating and manually controlled carousels must ensure that users…
- can access all functions using only the keyboard, including providing a prominent keyboard focus indicator
- are provided with images and controls that have alternative text, or another form of accessible name
- encounter images and controls that provide sufficient contrast and that do not use color alone to convey meaning
- hear content upon manual transition when using a screen reader
- will not encounter problems when the carousel updates
An example of an accessible carousel is the WAI-ARIA Carousel Example.
Potential Problems
Animated elements and carousels can be implemented incorrectly and create accessibility issues. Below are some common issues and how to address them.
For brevity, pause/play buttons, next and previous slide buttons, and other carousel control buttons are collectively referred to as "controls".
Controls are not buttons
Pause/play buttons, next and previous slide buttons, and other controls for animation and carousels should be coded as standard <button>s. Sometimes these elements are incorrectly coded as links. Using links as carousel controls can make navigation confusing for keyboard and screen reader users. Links are about navigating to a new page or to a particular place in a page. Buttons are about function, like pausing or playing animated content.
Links also have different keyboard interactions than buttons. Buttons can be activated with Enter or Spacebar, but links are only activated by Enter.
Controls cannot receive keyboard focus
All interactive elements that provide functionality for mouse users must be keyboard accessible. Sometimes elements that are not meant to be interactive (e.g., <div>, <p>, or <a> without the href attribute) are made interactive through JavaScript event handlers like onclick. When pause/play buttons, next or previous slide buttons, or other controls for animation or carousels are made out of these elements, keyboard and screen reader users are unable to directly navigate to these elements. The best way to solve this problem is to change these elements into standard <button> elements.
Controls do not have accurate accessible names
Sometimes, controls do not have accessible names or have accessible names that don't convey their purpose and visible labels. For example, sometimes the next and previous slide buttons on a carousel do not contain text (or an image with alternative text) or have descriptive aria-label attributes, and are simply announced as "button". Previous slide buttons should present "Previous Slide", Next slide buttons should present "Next Slide", and so on.
If a control has two different states, like a pause/play button, the accessible name and state must update when the button is activated.
The standard icon for a "Pause" or "Stop" button is a pair of parallel vertical lines:
While the animated content is paused, the button image should have alt of "Play" or "Start", or the button should have aria-label="Play" or aria-label="Start". When the user activates the button these should be changed to "Pause" or "Stop".
The standard icon for a "Play" or "Start" button is a right-facing equilateral triangle:
It can be helpful to describe what the control corresponds to, especially when there are multiple animated elements or carousels on a page. For example, the "Start/Stop" button on an auto-rotating carousel could have aria-label="Start automatic slide show" and aria-label="Stop automatic slide show".
Scripting must be used to dynamically update the accessible name, visible label, and icon each time the button is activated. These should always align with the actual state of the animated content.
Focus is lost
In some carousels, when the current slide in the carousel has keyboard focus and then disappears as the next slide enters the screen, focus is lost. This can cause several serious problems for screen reader and keyboard users, such as setting focus back to the beginning of the page. Make sure focus is reassigned to the next slide in the carousel before the focused slide disappears. Another option is to pause animation while the slide has keyboard focus, or when the user is hovering over it with a mouse.
New slide content is not announced
When screen reader users activate the next or previous slide buttons in a carousel, the new slide content should be announced. Sometimes, the new slide content is not announced, which makes it difficult for screen reader users to scan through the carousel slides. Make sure that when automatic rotation is turned off, the carousel slide content is included in a live region.
New slide content is not announced
When screen reader users activate the next or previous slide buttons in a carousel, the new slide content should be announced. Sometimes, the new slide content is not announced, which makes it difficult for screen reader users to scan through the carousel slides. Make sure that when automatic rotation is turned off, the carousel slide content is included in a live region.
No keyboard focus indicator on the content in slides
The content within the slides must have a keyboard focus indicator (the line that appears around links in the page when they have keyboard focus). Without it, it is extremely difficult for sighted keyboard users to navigate the carousel. Ensure sufficiently visible keyboard focus indicators are present.