WebAIM: Animation and Carousels

WebAIM: Animation and Carousels
Animation and Carousels
You are here:
Articles
> 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

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. 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.
prefers-reduced-motion
Modern browser and/or operating systems provide setting for users to indicate their preference for no or reduced animation or motion. CSS can be used to determine if this setting is enabled and, if so, to apply different styles to the page elements. The
prefers-reduced-motion
media query supports a more accessible experience for users that are highly distracted by movement in web pages.
Code Example
.animation {
transition: all 0.2s ease;
...

/* Remove animation. */
@media (prefers-reduced-motion: reduce) {
.animation {
transition: none;
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

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.,

, or

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

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.
Note
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.
Hidden slides receive keyboard focus
Incorrectly implemented carousels can have slides that receive keyboard focus while they are hidden. This results in the keyboard focus indicator disappearing. This can confuse users and cause them to lose their place.
When a slide is hidden, the contents should not be accessible, including elements that otherwise could receive keyboard focus. Using CSS
display:none
or the
hidden
attribute will visually and programmatically hide the contents.
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.
Nov 25, 2025
Related Resources
Accessible Rich Internet Applications (ARIA)
JavaScript
Keyboard Accessibility