Web accessibility & animations: strategies for success
Hey, web animations can be accessible, too!
On the surface, animations and accessibility can seem at odds. Once you understand them, however, you can quickly see how little considerations can make a big quality of life difference for users of all abilities.
For the purposes of this article, we'll focus only on the web, but it's worth pointing out how accessibility applies everywhere consumer products exist: phones, tablets, checkout kiosks, and heck, even doors (shoutout to Norman doors). In fact, I'd go as far as to say poorly designed "things" are in many ways an accessibility concern.
First, we'll cover authoritative requirements on web accessibility, then we'll explore specifics of tools and strategies you can use. There are also extra resources at the end for further learning.
Web Content Accessibility Guidelines (WCAG)
The key component to understanding web accessibility is ensuring it complies with POUR. There are three levels of compliance: A, AA, and AAA. In general, AA is the preferred minimum and the ADA recognizes WCAG in its requirements.
For animations, key requirements to think about include SC 2.3.1, 2.3.2, and 2.3.3:
The key points are:
- Hide, pause, and stop (2.3.3): Give users the ability to control an animation by stopping or hiding it completely.
- Avoid flashing (2.3.1): Avoid content that flashes or ensure it's within the allowed threshold.
- Flashing threshold (2.3.2): Ensure flashing doesn't exceed 3 times in 1 second.
There are some exceptions, in particular for SC 2.3.3, where animations minimal enough or critical to an interaction can be permitted (although they still can't violate the other two criterion).
Impact
What about real world impact? What types of disabilities/illnesses affected by animations?
Some individuals have a vestibular (inner-ear) disorder, giving them sensitivities to motion, causing nausea, vertigo, dizziness, and headaches.
Others have cognitive disabilities, where animations can actively confuse and disorient them, preventing their access to information or from using the website altogether.
Enter Animations
If you've been on the internet for more than five minutes, you've probably seen all sorts of animations.
Animations are obvious, visual features, whereas accessibility is often more subtle for folks without disabilities. Accessibility aids individuals with issues like vision, motor, and/or cognitive impairments.
On the web, animations utilize HTML, CSS, and JavaScript to create movements in user interfaces. HTML adds semantic structure, whereas CSS and JavaScript define the structure of an animation.
Animations can be automatic (e.g., without user interaction) or interactive (e.g., a button press).
Technical Details
CSS
Currently, CSS is the most common and approachable entry point for creating web animations.
User Preference
No better place to start than by acknowledging the prefers-reduced-motion
media query. Don't forget to have a fallback!
.animated-element:hover {
transition: transform 0.3s ease;
transform: rotateY(45deg);
}
/* reduce animation effect */
@media (prefers-reduced-motion: reduce) {
.animated-element:hover {
transition: transform 0.1s ease;
transform: rotateY(10deg);
}
}
Alternatively, you can completely prevent the animation; although it's reduce, not stop, after all.
Redirectable Animations
The more complex your animation, the more you need to consider specific methodologies around how users can interrupt and cause elements to be redirected in the interface.
The quick note I'll make is to be aware of how your animation can be interrupted. If a user quickly cancels or interacts with something else on a page, causing elements to change mid-animation, the elements can otherwise jump or drop frames (rightfully causing confusion!).
Emil Kowalski did a write up of his work building a React component that initially had this exact problem. Worth the read if you're interested in the coding side.
In his case, using keyframes
caused the animation to "snap" to the last frame of the animation when interrupted (in this case, rendering multiple UI elements quickly and successively), causing frame drops/skipping. Once he switched to using the transition
property, the animations became fluid again.
Allowing CSS transitions to be interruptible is part of what makes them robust and resilient (calling back to the POUR principles from the beginning). Without this consideration, users are likely to consider your website/product low quality, or worse, feel confused or succumb to physical effects.
This is all to say that animations that feel natural actually go a long way in not distracting a user from accomplishing their goal.
JavaScript
In JavaScript, user motion preferences can be detected with the matchMedia method in browsers.
const isMotionReduced =
window.matchMedia('(prefers-reduced-motion: reduce)')
if (isMotionReduced) {
// handle low- or no-motion alternative
} else {
// handle animation
}
As an aside, the Web Animations API has become quite robust and feature-full in the last few years.
If you're like me, you probably don't want to code custom animations in JavaScript every time. Thankfully third party tools like Motion, GSAP, and React Spring provide a better developer experience.
Speaking of performance…
A Note on Performance
Writing a performant and well-designed animation contributes to accessibility, believe it or not!
A poor performing animation can make your website look broken and cause confusion. You've probably seen such animations in the wild.
One way to work within the constraints of browsers is to prioritize hardware-acceleration (moving the operation to your machine's graphics card).
Normally, animations use your computer's CPU. This is fine for simple animations, but what about the complex ones? CSS properties that benefit from hardware-acceleration include opacity
, transition
, and filter
. More are slated to be supported, but these are the big ones right now.
If you aren't seeing the performance you expect from these properties, you can try using will-change
; especially if your animation uses 3D-space, for example:
.3d-element {
will-change: transform;
transform-style: preserve-3d;
transform: /* value */;
}
Some suggestions with this feature:
- You shouldn't overuse it.
- Remove your
will-change
declaration after animations complete.
Over-using hardware-acceleration can ironically cause further performance degradation. That said, browsers generally handle this intelligently and will do the right thing by default.
Finally, be aware of layout shift. If your animation affects surrounding elements, the browser will need to do extra work to re-render content constantly, taking up more memory and causing jitter (we could write an entire post just about the render lifecycle of a browser, but for now, we'll keep it light 😉).
Closing thoughts
If you should take away anything from this post, it's this: accessibility is an opportunity to enhance the user experience.
We carry a deep responsibility to help users and customers succeed when using our websites and products.
As Don Norman said: Human error? No, bad design.
Additional resources
Here are some links for further reading:
Published
Author
- George Treviranus