The modern internet is full of movement. Animations, carousels, and interactive controls are common, and they’re effective tools for capturing users' attention and keeping them engaged.
But for many users, motion is a headache — in some cases, literally. Moving content can trigger physical reactions for people with vestibular dysfunctions, which affect the body’s balance systems. Animations can also create issues for people who use screen readers (software that outputs text as audio or braille) and other assistive technologies (AT).
That’s not to say that you can’t use motion in your web content. However, developers have a responsibility to consider the preferences of their entire audiences.
Fortunately, CSS (Cascading Style Sheets) has features designed to accommodate users with disabilities. The prefers-reduced-motion feature is a powerful example: It tells web browsers that the user would like to limit motion effects, which allows the browser to present a different type of experience.
Here’s what to know when using prefers-reduced-motion to improve your content.
The CSS prefers-reduced-motion is widely supported
Most operating systems allow users to set their motion preferences in the system settings. For designers and developers, it’s a good idea to toggle those preferences when testing content. Here’s how to find the setting:
- Windows 10: Start > Settings > Ease of Access > Display > Toggle “Show Animations in Windows.”
- macOS: System Preferences > Accessibility > Display> Check “Reduce Motion.”
- iOS: Settings > Accessibility > Motion> Toggle “Reduce Motion.”
- Android: Settings > Accessibility > Toggle “Remove Animations.”
Every major web browser supports reduce-motion, including Chrome, Edge, Firefox, Safari, and Opera. Read the MDN Web Docs prefers-reduced-motion guide to see examples of syntax.
Implementing this feature isn’t especially difficult, but it’s important to be consistent. You’ll need to provide a prefers-reduced-motion media query for every animation. Needless to say, this is much easier if you prioritize accessibility from the first stage of development.
“Reduced motion" doesn’t necessarily mean “no animations”
The easiest way to implement prefers-reduced-motion is to get rid of all animations. However, that’s not always the right approach.
After all, your website uses animation for a reason. Eliminating all animations can create a less engaging experience for users. Some animations can also make your content more understandable for people with attention disorders and other conditions.
Instead, you can simply choose animation effects that don’t create a sense of motion. For example, instead of scaling, rotating, and wave effects, you might choose fade-in, dissolve, and color-change effects as the reduce-motion animations.
Those effects can maintain an interesting visual presentation without creating potential triggers for people with vestibular motion disorders.
Where possible, don’t rely on reduce-motion to provide accessible experiences
You can — and should — use prefers-reduced-motion when creating your content. However, remember that the goal of web accessibility is to accommodate as many users as possible.
People may be unaware of the reduce-motion toggle, or they might be using a shared computer where they can’t change the setting. Some people may prefer to reduce motion at certain times, but not at other times. Wherever you can, you want to give people options.
To that end, the best practice is to provide on-page interactive controls for moving, flashing, or blinking content. The Web Content Accessibility Guidelines (WCAG) addresses this in Success Criterion (SC) 2.2.2, “Pause, Stop, Hide,” which requires a mechanism for limiting motion.
Technically, the CSS prefers-reduced-motion feature is a mechanism, so it’s sufficient for WCAG conformance — but a simple “pause" button might be more effective for some users.
You can also improve the user experience by limiting content that creates a sense of motion:
- Try to avoid animations that last for more than five seconds.
- Avoid content that flashes more than three times in any one second period. This is essential for meeting WCAG SC 2.3.1, “Three Flashes or Below Threshold.”
- Avoid autoplay, especially if the content has sound. Learn why autoplay is an accessibility no-no.
Finally, use semantic HTML and CSS wherever possible to make sure that your content works with screen readers and other assistive technologies. Test your content with a keyboard alone (no mouse) to make sure that the focus moves in a predictable way.
By considering your audience when designing your website, you can create visually interesting content that appeals to every user. For more guidance, download our free eBook: Developing the Accessibility Mindset.