We can not start without saying that animation can add to the content – it can draw attention, add dramatic meaning, make experiences more exiting and even act as an add-on to human interfacing with computer.
On the other side, in it’s extremes, animation can make humans sick, sometimes even trigger seizures that can have extreme effects.
Animation on web and mobile
Animation is a big part of our communication on the web and mobile, from native mobile, tablet and desktop interfaces to animated (GIF) images, parallax single page sites, button, slider and progress animations and so on.
One of main agendas with animation usage is to attract users’ attention. Guiding user focus to maybe mimic natural movements, maybe movement of design elements in the peripheral view that we are hard-wired to recognize as potential danger, sometimes just demonstrating visual hierarchy.
There are so called micro and macro animations – micro animation can be an animation in a single element and macro can be the animation of parts of surface with multiple elements at once, orchestrated in a special way. Designers are trying to enrich the users experience, create it attractive and provoke delight. They use frequency, speed, duration, shape changes and so on, so it can be a lot of trying and failing. Animation has it’s own best practices, like for example keeping it under 100ms limit if we do not want our micro-animation to appear slow and laggy.
Think of users that do not want or that can’t have animation
Animation is all around us, therefore it is crucial to think before adding it. It may be exiting at first but also disturbing and annoying to users. Therefore it is also crucial to give users control over animation.
Web content accessibility guidelines have therefore defined some basics to respect web and mobile accessibility and with them – trying to prevent problems for users that may have issues with animation.
Modern technology offers plenty of tools for animation and we have all probably experienced pleasant and not so pleasant examples of animation on the web and on other digital surfaces. But on the other hand animation can cause some people to struggle with their digital experience and maybe just add to their cognitive load – making it more difficult to understand the content, maybe even to read the text, preventing them to concentrate and in some cases animation can cause sickness, dizziness, vertigo and in some more extreme cases even seizures if user has a medical condition related to so called vestibular balance.
Some people have difficulties concentrating and for them animation could mean they can not focus on the information. People with (inner) ear conditions, epilepsy and brain injuries can be extremely sensible to animation and can experience balance problems, blurred vision, disorientation, nausea, vomiting even anxiety and falling.
So we must give them options to control animation, and in some cases we should not be running animation based on users settings.
At the same time – how can visually impaired or blind users benefit from animation that is adding to the content? They need to be informed about the context of it. So they need a text alternative when animation adds to the content.
WCAG helps us make animation more accessible
There are web content accessibility guidelines that we should respect. And they should serve a a starting point. Let us be introduced to them;
- 2.2.2 – Pause, Stop, Hide on level A (opens in new window) – is basically telling authors to give user a possibility to pause, stop or even hide animation that starts automatically and lasts more than five seconds and is presented in parallel with other content. Think of carousels, video backgrounds, even animated graphics. So – user has to be able to pause / stop or hide it. That’s the main point.
- 2.3.1 – Three flashes or below threshold on level A (opens in new window) – is a smart limitation based on scientific research and preventing seizures due to sensitivity. Please prevent anything flashing more than three times per second. That goes also for parts of video and games to be clear.
- 2.3.3 – Animation from Interactions on level AAA (opens in new window) – is again putting user in control. Animation triggered by interaction, unless it is essential to functionality, should be user-controlled. Scrolling and slide decks for example are an essential functionality, while flipping the button on focus or hover is not.
User controllable settings and CSS media query called prefers-reduced-motion
Animation creators can use multiple technologies to animate on the web, most commonly JavaScript and/or CSS. It is beyond the scope of this post but should be fairly easy to make controls for JavaScript that and make them session-persistent.
For CSS there is luckily a special media query called prefers-reduced-motion. It was actually introduced by Apple’s Safari in version 10.1, back in 2017 (opens in new window). It was accepted by other browsers luckily, so it is now incorporated in majority of user agents out there (opens in new window). So we should always use this simple media query to reduce the animations made in CSS. It is as simple as responsive media query, we just need to be consistent when making CSS animations so that we include their negation when user prefers reduced motion (for example @media screen and (prefers-reduced-motion: reduce) { }).
To test it we have to visit our devices motion settings, or when using Google chrome just find the “Animation” in “More tools” and pause it – or choose “Rendering” and find “Emulate CSS media feature prefers-reduced-motion” and turn it on.
Use animation with care, make it user-controllable
To conclude – animation can be used for good and it can be bad, so use it with care, make it user controllable and you should be fine. When adding external media, make sure it will not cause problems or just be friendly and inform users about potential problems if you know they are there.
Respect the user’s settings, as always.
