Animated interfaces can cause headaches, nausea, dizziness, and other health problems for many people. The most affected groups are people with vestibular disorders, epilepsy, and migraine sensitivities. However, anyone can experience similar issues if subjected to excessive motion on the screen for a longer period of time.
In this guide, I’ll share a couple of best practices to address the needs of users who literally get sick of your animations.
International Day of Persons with Disabilities
The publication date of this article is no accident: December 3rd is the United Nations’ International Day of Persons with Disabilities. Today we’d like to raise awareness and demonstrate what we can do with inclusive web design.
Side Effects of Animations
The vestibular system includes parts of the inner ear and brain, responsible for sensory information processing and spatial orientation. People with vestibular disorders experience symptoms like motion sickness, balance problems, chronic dizziness, headaches, and nausea when looking at large-scale motion on the screen.
But how common are these problems? According to Vestibular.org, very. Researchers estimate that:
“..as many as 35 percent of adults aged 40 years or older in the United States (approximately 69 million Americans) have experienced some form of vestibular dysfunction” – Vestibular.org
Flickering and flashing animations can also trigger seizures in people with photosensitive epilepsy.
This certainly doesn’t mean that you can’t use animations at all if you care about accessibility. Let’s look at some best practices you can implement to address the needs of users who experience problems from animated interfaces.
1. Consider Relative Size of Motion to Viewport
Small animated elements such as a button that slightly changes color on hover won’t be much of a problem. Animations that cover a huge area of the screen are the real offenders you need to be careful about. When designing an animation always think about the relative size of movement to the screen.
The higher this ratio is the more people will be triggered by the animation. This rule applies to mobile interfaces as well. An animation that looks relatively small on desktop can cover half of the screen on a mobile device.
2. Be Wary of Parallax Scrolling
The concept of parallax scrolling (and its inherent problem) is that the foreground and background move at a different speed. When it’s done drastically, parallax scrolling is a good example of large-scale animation that might cause the symptoms mentioned before. You can still use subtle parallax effects if you want, but there are a number of behaviours you should avoid by any means.
“Scrolljacking”, first and foremostly. This is when the scrollbar is manipulated to behave independently of the user’s efforts and intents. It’s not a nice experience to begin with. But, when combined with parallax scrolling, the animated background begins to move at its own speed and your website becomes basically unusable for people with vestibular disorders.
Also avoid horizontal scrolling when using parallax effects. Horizontal scrolling on a website is a surprise to most users and not always a pleasant one. As a general rule of thumb, always think carefully about surprising movements on the screen: they tend to make people with balance problems lose direction and the symptoms ensue.
3. Allow Control of Sliders and Carousels
Sliders without play, stop, and pause controls present a problem to anyone who is actually interested in the contents of the slider (which is probably not a huge crowd). According to Yoast SEO’s excellent “Sliders suck” analysis, only 1% of users click on sliders, but you should still think about them. Even if people with vestibular and other disorders find themselves in the 99% who don’t care about the slider at all, constantly moving slides will still make them sick.
Always provide more than one ways for users to stop, pause, and restart your slider or carousel. There are a number of techniques you can use, such as:
- Left and right arrows icons to let the user move the slides.
- A clickable thumbnail of each slide below the slider.
- Icons (usually larger dots)—one for each slide.
- Traditional play, stop, and pause icons below the slider, similar to the ones used in media players.
Also, avoid animated effects on the slides. Animations inside animations are super disturbing for user experience and seriously harm accessibility (the same goes for animations on parallax sites: a huge no-no).
Besides sliders, WCAG 2.0’s 2.2.2 success criterion also recommends providing pause/stop/hide controls for any auto-updating information that:
- Starts automatically.
- Is presented in parallel with other content.
4. Specify the Duration of Animations
Animations which happen too quickly can also be troublesome for users with accessibility needs (and probably anyone who wants to process the presented information). Luckily, CSS makes it possible to control the duration of both animations and transitions.
To set up time limits, you can use the
transition-duration properties. Their usage is pretty straightforward. For instance, the following code gives 2 seconds for a transition animation to complete:
Or, the same with the
transition shorthand property:
transition: width 2s;
The ideal duration of time depends on the relative size of the animation to the screen. What is okay for a smaller animation might be too fast for a larger one. It can be a good idea to use different durations for different viewport sizes as well.
You can also define the number of times an animation cycle is played. This feature is only available for keyframe animations, as transitions don’t loop; they run only once. You can use the
animation-iteration-count property in the following way:
You can set
infinite as the value for
animation-iteration-count, however infinite loops are not very good for accessibility. Especially, if you don’t provide any way for users to stop or pause the animation whenever they choose.
5. Use HTML Videos Instead of Animated GIFs
Animated GIFs are extremely popular these days; websites use them all the time. However, their impact on accessibility is barely ever questioned and is actually quite disturbing. Accessibility issues get especially nasty when a website uses several animated GIFs on the same page. Just think about list-type articles in which each item is decorated with a separate GIF animation, frequently moving in all kinds of unopredictable directions.
The problems with animated GIFs are auto-playing, infinite looping, and the lack of user control, to be precise. Google Developers also cite performance problems (animated GIFs can be really huge, like 13.7 MB in the analyzed example). One of the possible solutions is replacing them with HTML videos that run natively in all modern browsers.
There are a number of tools (e.g. FFmpeg) you can use to convert animated GIFs into different video formats. HTML5’s
<video> tag allows you to define multiple sources for an embedded video. You can use three video formats: MP4, WebM, and Ogg. MP4 has the best browser support, however WebM is somewhat smaller in size.
For instance, after converting an animated GIF to MP4 and WebM formats, you can use the following HTML:
<video controls width="300">
<source src="image.webm" type="video/webm">
<source src="image.mp4" type="video/mp4">
Sorry, your browser doesn’t support embedded videos.
By using HTML videos instead of animated GIFs, you enable users to stop or pause the animation or opt out of watching it at all. Plus, you significantly improve page load time which is also an important metric of accessibility, especially because of mobile users and people in low connectivity areas.
Imgur and Gfycat also use HTML5 videos to display animated GIFs on their websites (you can test it with your browser’s developer tools). Thus, the technique is already widely tested in production.
As an alternative to the
- Add the library to your web page using the
- Use the
data-gifffer attribute instead of
src on your gif image.
Gifffer() whenever you want.
Here’s a demo (thanks to Patakk for the animation) that shows how Gifffer works:
Note the use of
data-gifffer-alt instead of the
alt attribute to support screen reader users. Additionally, you can use three optional
data-* attributes if you want:
data-gifffer-width in pixels or percentage.
data-gifffer-height in pixels or percentage.
data-gifffer-duration in milliseconds.
Take a look at some more code examples on Gifffer’s GitHub Page.
Vestibular disorders, epilepsy, and migraine sensitivities are not the first things we think about when discussing accessibility. However, they do affect many users, so paying attention to animation accessibility is just as important as other aspects of accessibility.
There aren’t many articles addressing these problems. Val Head was the first who covered the subject in length on A List Apart in two excellent articles:
- Designing Safer Web Animation for Motion Sensitivity
- More Resources on Accessible Animations
Make sure you check them out, especially the first one, as it shows a couple of examples of bad animation design that will truly make you dizzy. Allison Ravenhall also discussed the accessibility of animated GIFs lately on Smashing Magazine. And, for more reading on Tutsplus have a look at my previous article on keyboard accessibility–that’s a pretty neglected topic, too.