It's official: Level Access and eSSENTIAL Accessibility are becoming one! Read the Press Release.
Positive check mark beside best practice

user looking dizzy at screen because of animationSince the arrival of HTML5, the web has seen a tremendous increase in complex animations. Whether they are decorative or explanatory, animations must be built with accessibility in mind. Animations can have detrimental effects for some users. People with concussions, vestibular disorders, Meniere’s Disease, motion sickness, autism, and ADHD/ADD have all reported negative side-effects from movement on the screen. Effects can range from seizures and migraines to dizziness and nausea to distraction from completing the task at hand. There is still much research to be done on how these animations affect users, what is “good” versus “bad” and how it affects users, but recent CSS and JavaScript updates have provided us ways to give the user the control they need for their best experience.

Accessibility Standards Can Help

The Web Content Accessibility Guidelines provide us some rules for how to make this happen. The first is the Success Criterion 2.2.2, Pause, Stop, or Hide. This states that any blinking, scrolling, or moving content on the screen that auto-plays needs controls to pause, stop, or hide the animation. Additionally, if the animation lasts more than five seconds or is provided in parallel to other content, these controls are necessary. We also have Success Criterion 2.3.1, Three Flashes or Below Threshold, requiring that we avoid any content that flashes more than three times in a one second period.

With WCAG 2.1, we introduce a new success criterion at the AAA level, 2.3.3 Animation from Interactions. In this criterion, we see that motion triggered by interaction can be disabled it unless it is essential to the functionality.

What does essential mean?

If you are opening a select element, moving from the closed to open state is essential animation. Taking a half second to animate a smooth transition from open to close is not essential.

Scrolling is another great example. As the user scrolls, content may move in and out of the viewport (or in the case of parallax, move at different rates). This movement is not essential to the act of scrolling and should be built in a way the user can prevent.

State of the Art: prefers-reduced-motion

The new CSS media query, prefers-reduced-motion, allows developers to provide a fall back for users who indicate that animation is problematic for them.

This media query has two accepted values and a default state:

  • When providing the value of ‘reduce’, systems that support the media query will respond to the CSS defined in the section. This is also the default value, so @media and(prefers-reduce-motion) returns a value of true or reduce.
  • The other value that can be provided is ‘no-preference’.

This offers us two ways to build our CSS. We can wrap all animation in the no-preference setting and fall back to the static look. Alternatively, we can compose the site with animations on and use the default or reduce value to unset all our animations. This is the process Animate.css uses. As it is a CSS media query, we can also look for it using the JavaScript windows.matchMedia()function.

How does this work?

The prefers-reduced-motion media query looks for operating system settings requesting to remove extraneous animation. For example, on iOS, if you tap to open an app, it will zoom from very small to filling the screen. This motion can trigger negative effects for people with disabilities. If you turn on the Reduce Motion setting under Accessibility, this animation is one (of many) that is turned off. Developers can check this setting and turn off the extra animation for the user.

Incomplete Support and What to Do About It

But what if the media query is not supported? This is a real concern. Safari on Mac OS X and iOS support the media query, and Firefox has it as of version 63which was released on October 23rd, 2018. Both Edge and Chromium have adding the media query listed as an issue in their respective trackers. Mac OS X, iOS, and Windows since version 7 all allow you to turn on a reduced motion setting in either the accessibility menus or display settings. Android still does not have this.

Since we can’t rely on it in all circumstances, developers are recommended to implement their own solution. by the Mozilla groupis a great example of this. This site designed to teach about the animation API uses a switch at the top of the page to turn off extra animation. It lowers the movement overall but keeps some small movement, so you can learn the API. I began prototyping a version of this in February of 2015 that demonstrates a way to add a switch into the page allowing reduced motion.

 What’s Next?

We need to do more research. Conducting usability testing with people at all disability levels and observing how different animation types and styles affect them will help us shape the next step. I’d like to see this research as I think this problem deserves to be at the WCAG AA level. Of course, that is one person’s opinion (because it affects me).

As developers, we need to be forward thinking and start building sites using prefers-reduced-motion now, even before it becomes part of the official guidelines. Build with the Progressive Web Application mindset, where we have a basic site and add animation behind the media query. Incorporate a custom switch for Edge and Chrome. And most of all, help encourage the Chromium and Edge teams to include the media query in their next builds so we can build standardized code in our applications.