Accessibility and Motion
How to design the delightful user experience you want for your sighted / non-motion sensitive users, without triggering distraction, nausea and migraines in the rest of us
“Moderation in all things is the best policy.”
- Roman comic dramatist Plautus (c.250–184 BCE)
While Plautus never had to deal with motion in the context of technology, his commentary on moderation is definitely relevant to the topic of making motion accessible to all users. The following elements are common sources of motion on web pages and in mobile apps:
- A small “jiggle” of a field outline acting as a subtle reminder that data must be entered before a form can be submitted
- Auto-playing carousels and videos
- Simple unlooped animated .GIF
- Microsoft Clippy-like “LOOK AT ME” continuously-looping, attention-grabbing animation
You may be one of the lucky people who have learned to ignore or even benefit from motion. Yet there are many distinct groups of individuals who are adversely impacted by motion which can include people with chronic motion sickness, dyslexia, epilepsy, migraines, attention deficit disorder, anxiety, people on the autism spectrum, and screen reader users.
Here is a quick review of the issues to consider when considering adding motion to your website or mobile app to :
- keep motion compliant with the WCAG standards;
- wow the people you want to wow; and
- not tick off the motion-sensitive people in the world.
Step 1: Follow the WCAG motion guidelines
There are two key A-level guidelines in WCAG pertaining to motion. These both are absolutely, critically, non-negotiable.
- 2.2.2 is the “Pause/Stop/Hide” guideline for automatic motion lasting more than five seconds
- 2.3.1 is the “Three Flashes or Below Threshold” guideline aka the “don’t trigger a seizure” rule
2.3.1 is the only WCAG guideline where you can literally kill someone if you ignore the guideline or implement it incorrectly. I cannot overstate how important it is to avoid the use of content that can trigger photoepileptic seizures either through explicit flashing (think: sparkly fireworks, or flashes simulating gunfire in a FPS game) or psuedoflashing (i.e. the use of optical illusions).
2.3.2 is also non-negotiable. The WCAG language is non-specific, to be compliant you need a “mechanism” to stop motion. Designers hate pause buttons, but that is the easiest way to comply. If a pause button that toggles back and forth to play is used, the coders will also need to handle announcing the state changes.
I was really disappointed when the new 2.1 guideline 2.3.3 titled “animation from interactions” was moved from Level AA to AAA. This guideline would be beneficial to me since I am someone who gets motion sick at the drop of a hat to the point where I cannot set foot in an IMAX theater or watch waves on a large computer screen or TV. A single place to disable all motion (including the incredibly evil parallax) would have been nice, but AAA means no one is obligated to implement it. However, if you want to create the best user experience pertaining to motion, you need to provide the ability to shut it off.
Step 2: Honor the choices users have made in their OS and Browser settings
There are numerous places in various operating systems and browsers where users can tweak motion settings. From the user perspective, however, modifying those settings only solves the motion problem if your code checks to see if one of these settings have been modified from the default value and applies the updated setting requests.
Mobile — iOS
- Use the toggle located at Settings->General->Accessibility-> Reduce Motion.
Mobile—Android
Like most things accessibility AND android, the Android approach to reducing motion is less well thought through and harder to accomplish than iOS. Fortunately you only have to do it once.
- Turn on “enable Developer Options” Don’t worry, it won’t break your phone if you aren’t a developer. But it will expose the motion option you want to tweak.
- Under developer options (once you’ve enabled it) there are three things to set to “animation off”:
- Window animation scale
- Transition animation scale
- Animator duration scale
Operating Systems — Windows
- Go to Control Panel > Ease of Access Center > Make the computer easier to see panel and check the “Turn Off Unnecessary Animations” box.
- Animations can also be disabled individually, read this article for more details
Browser-level
- Chrome (version 74 and later) and Firefox (63 or later) support a user preference media query called
prefers-reduced-motionthat allows users to implement a motion-reduced variant of their site. - In Safari, users must turn flip two separate switches to turn off all animation. That is because iOS 12 conceptualizes Java animation and Web animations as two separate beasts. Settings > Safari > Advanced > Experimental Features > Web Animations takes care of one, CSS Integration takes care of the other.
If someone has gone through the trouble of discovering and customizing any of these “motion killing” options, chances are that they are one of the people that are adversely impacted by motion. These will not be happy users of software that have ignored these choices. No one voluntarily continues to use software that makes them feel like they are going to hurl.
Step 3: Give users an additional mechanism from the site/app itself to turn motion off
You can’t trust that everyone is going to be capable of finding one or several teensy, weensy, hidden variable settings deep in the bowels of their OS or Browser to improve their motion experience. If that were the case, you would never see visual page-level options to increase font size. Everyone knows you use Ctrl-+ and “pinch to zoom” for that, right? (snark). By doing all three steps identified in this article, you are creating a belt and suspenders approach that should make all of your users happy.
How you would technically implement all three steps depends on whether or not your software requires a login, works for guests, or does both.
Associate motion as a login preference
If all of your motion is behind a login wall, it is extremely easy to add a preference to the login for motion off and on. With this type of mechanism, you have the added benefit of being able to fine-tune behind-the-login-wall motion personalizations with different settings for different types of motion, such as in the Android example above. For example, users could leave motion On for error messages (i.e. because errors are important) and turn motion OFF for non-informative animated .GIF motion (which is only there to entertain).
Associate motion with cookies
If your motion is not behind a login wall, the only easy way I can think of accomplishing a similar motion approach to the login preference discussed above is to use cookies and menu options that allow the user to select the motion options they want (which then updates the cookie values). If you can think of other options, please feel free to comment below.
The problem with a cookie-based approach is it opens a different can of worms. “What if all my cookies are blocked” and “What if I have to blow away my cookies” and GDPR headaches are all associated with a cookie-based motion governance system. So while cookies for controlling motion are technically doable, I wouldn’t necessarily recommended this mechanism unless ALL of the cookie issues are thought through.
