Accessible motion: why it’s essential and how to do it right
Motion must be accessible.
Motion and animation can dramatically improve the user experience of web interfaces by guiding users on their journey, bringing delight to static pages, and so much more. What’s equally important is that we ensure animation creates the best possible experience for every user, not just the seeing ones.
Motion should be used with intention to solve user problems and bring delight without disorienting users. Excessive motion can not only distract users but also increase page load times and cause accessibility issues. Intentional, subtle motion is key to improving user experiences and making motion accessible.
So what is motion accessibility? It’s actually quite simple. Motion accessibility is designing and developing motion so it enhances the experiences of some users but does not impede the experiences of others. Like all aspects of the work we do, when we use motion to improve user experiences we must also consider those who cannot experience motion.
Luckily, there are some very straightforward steps you can take to ensure your motion is accessible.
Who does this affect?
Before we talk about how to make motion accessible, we must first introduce the people who need accessible motion. There are several different groups of people who cannot experience motion or need to avoid it: people with vestibular disorders, people who have low vision, people who use a screen reader, and people who are triggered by visual stimuli.
Let’s start with vestibular disorders. Since I can’t explain it as well as vestibular.org, here’s their definition:
“The vestibular system includes the parts of the inner ear and brain that process the sensory information involved with controlling balance and eye movements. If disease or injury damages these processing areas, disorders of dizziness or balance can result.”
This means when anyone with a temporary or permanent vestibular disorder views motion on their screen, it can cause dizziness, nausea, imbalance, and headaches. That is not the experience we want to give our users.
People with low vision require motion accessibility because it may not be visible to them. Someone with low vision may be zoomed in on a part of the screen and may miss motion entirely if it’s on a different part of the page, or even become overwhelmed when it covers their screen. Consider what it might look like to zoom in on this text and miss an important notification happening in another part of the page, or if the text you are reading is suddenly covered by a side panel.
Folks using a screen reader or other assistive devices will not experience motion at all — which means whatever purpose the motion serves or information that it conveys needs to be available to them as well. Keep them in mind especially if the motion adds or removes elements from the page.
Finally, there are many people who need to avoid motion because visual stimuli may be triggering for them. This includes people with epilepsy (who may have seizures due to bouncing or flashing), people with sensory processing disorders, and people with migraines, like me!
I work on motion every day as part of my job, but I hadn’t always considered myself a user requiring accessible motion. One day, I got a migraine while I happened to be working on motion and found that reducing motion in settings helped. While I was already passionate about accessibility and implementing accessible motion for others, this made me reconsider — when I make our interfaces accessible for everyone, that includes me.
How to make motion accessible
At this point, you might be thinking, “Why should I even add motion if it can be detrimental to so many people?” And the answer is simple: the benefits of adding accessible motion to your user experience far outweigh the negatives of not adding it, especially because making motion accessible is not very difficult to do. Motion can actually make a page more accessible to seeing users, as it reduces the cognitive load by guiding the eye to what’s important.
Like any other part of making webpages or software accessible, you have to take into account every person who might interact with this experience and make sure it would work for them. Accessibility must not be an afterthought for any part of web design and development, and the same applies to motion. It must be a consideration before an experience is built, during, and after. When we understand the experience for all of our users, then we can truly make useful and delightful experiences for everyone.
So, let’s recall our users in the last section and consider how to make motion accessible for them, in both the design and development of our interfaces.
Here are some rules you can follow to make your motion accessible:
- Keep motion design to less than a third of the page, and the animation at the point of focus. This ensures that low vision users will not be overwhelmed by motion covering their screen, or miss it outside of the part of the page they are zoomed in on.
- Avoid flashes and limit bounces to 3 times. Flashes and bounces can trigger epileptic seizures and be very disorienting for users with vestibular or sensory processing disorders. This is covered under WCAG, the Web Content Accessibility Guidelines.
- Similarly, avoid parallax scrolling and motion where the background and foreground move at different speeds. This affects people with vestibular disorders, as well as people who may be triggered by visual stimuli.
- Keep the duration short and the movement reasonable. UX motion typically does not last for more than 1 second, and even that is a little long. Animations other than UX motion can last longer, like an animated illustration. Using a shorter duration does not mean you should speed up the micro-interaction, but rather find a duration at which the speed feels natural for the size and movement of the object.
- Make sure motion does not hide or add elements in a place where screen readers or low vision people cannot find them. If you hide, add, or remove elements from the page, ensure that the code includes them in a way screen readers can still access the element and does not pull them out of context unless necessary.
- Design all elements of the page with and without motion, so users who prefer no motion can turn it off with a reduced motion setting. Make sure we are reducing cognitive load rather than increasing it.
- For videos, always include a pause button. This is also covered by WCAG.
- Provide a setting to turn off all motion on your website. While this may not be doable for larger sites, it is a recommendation from WCAG and may be an option for personal and smaller sites. Media queries can have nearly the same effect if that is not an option for you.
Media queries
Now that we’ve covered the basics of accessible motion, we can dive into how to code accessible motion.
In code, the most important thing you can do is use the “prefers-reduced-motion” media query to reduce or remove motion for users who don’t want it. This is also how we’ll show our alternative designs to those that prefer less motion.
Essentially, the media query checks to see if a user has set a preference for reduced motion. This allows you to create two options in your code, one for those who prefer reduced motion and one for those that don’t. The reduced motion preference can be set in your device’s system settings and is currently honored by all modern browsers.
If a user has not set a preference, then we can assume that motion will not affect their ability to use the page. We can use the query to show the full motion to these users. In most situations, I only write code for the full motion and put it inside the media query set to “no-preference.” This means that motion will only show for users with no preference, and there will be no motion for users who prefer reduced motion.
Alternatively, you could use the media query to provide two options: one for users with reduced motion and one for those with no preference. This is a totally valid way to reduce motion or handle situations where animation is absolutely necessary. In those situations, I would also ask you to consider how people using screen readers would interact with that element.
Here’s an example. If I am creating a side panel that slides in from the right, then my code should make the panel become visible even if it can’t use motion. If a user is not affected by motion, it will slide in, and if a user prefers reduced motion, it will statically appear on the screen.
In this case, I will keep the transform that moves the panel outside of the media query so that the panel appears either way. Then the motion will go inside the media query so that only those who can perceive motion without issue, and those who have not set a preference for reduced motion can see it.
On the other hand, let’s say I am building out a bounce animation, with only 3 bounces. When I code the CSS animation, I’ll place both the transform and animation attributes inside the media query set to “no preference,” so only those who haven’t requested reduced motion will see it. In this case, I will not set an option for those who have reduced motion because bounces can be triggering for so many people and it’s better to have no motion at all. This codepen shows this animation in action.
In summary, keep those affected by motion in mind while designing and developing. Let’s use motion to create fantastic user experiences for everyone, not just those who can experience it without difficulty.
References:
I stand on the shoulders of giants and have many people to thank for teaching me about this subject. I would like to both recognize and recommend these resources which can expand upon these topics in greater detail.
- Designing Safer Web Animation For Motion Sensitivity by Val Head
- How to Make Motion Design Accessible by Alik Brundrett
- Your Interactive Makes Me Sick By Eileen Webb
- Responsive Design for Motion by James Craig
- Making motion inclusive by Val Head
- What is Vestibular? by VERA
Stephanie Cree is a UX Engineer at IBM based in Austin, TX.
The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
The code samples above use a motion curve from IBM’s Carbon Design System, which is open-source.
