Talks Tech #50: Building More Inclusive Android Apps: Animation and Reduced Movement

iTunes – Spotify – Google – Video – More Episodes

Eeva-Jonna Panula, Accessibility Specialist and Senior Android Developer at Oura, shares her talk,  “Building More Inclusive Android Apps, Animation, and Reduced Movement.” She discusses disabilities and impairments that can be affected by motion on tech devices. She shares things that should be considered in making technology accessible and inclusive.

When I talk about accessibility, I mean that anyone, despite having disabilities or impairments, can use a digital product. This also means that these digital products work with assistive technologies such as screen readers or switch devices or different settings such as reduce motion or remove animations. Animations can actually trigger different kinds of symptoms such as nausea, dizziness, feeling disoriented, or seizures. They can also be really distracting. It’s not just about these disabilities, but I want to raise awareness. Vestibular disorders is an umbrella term for different disorders or conditions that affect the vestibular system, the system that affects balance. Some examples of these vestibular disorders are, for example, benign paroxysmal positional vertigo, vestibular migraine, Labyrinthitis or vestibular neuritis or many iris disease, age-related dizziness and imbalance or vestibular damage due to head injury or secondary endolymphatic hydrops. Traumatic brain injuries might cause some of these vestibular disorders, ear infection, migraines, strokes, and sometimes the reason remains unknown. Vestibular disorders can cause animations to be  not so pleasant. Cognitive disabilities, autism, and ADHD are examples of conditions that might affect concentration. 

I’m going to use Val Head’s article, Designing Safer Web Animation For Motion Sensitivity as a resource. Val Head found three reasons for movement being problematic. These are relative size of the movement, mismatched directions, and distance covered. If the animation is relatively big, it’s more likely to trigger symptoms than if the relative size is small. Even on a mobile phone screen, if the animation takes the whole screen, like a transition from one activity to another, that might be really problematic. It’s also about perceived space. Then the mismatched directions and speed is if you are scrolling one way and the movement goes another way, that might be really problematic. Parallax scrolling is another problem. Usually the speed directions are mismatched compared to when the user is scrolling down. This is more visible on the web, but I’ve seen it on mobile as well. The third one is the distance covered. If the actual screen is big and then it covers the whole screen, that’s really problematic, especially if it goes in a direction or at a speed that’s mismatched with scrolling. These were the three things I wanted to raise from Val Head’s article. The fourth problematic thing is movement near content. Not all animations are bad. Some can help to, for example, build connections between items and help users to understand relationships between two items or concepts.

There is a setting called either reduced motion or remove animations. On IOS, I think it’s called reduced motion, but then on Android it is most likely called remove animations and on the web, it’s called reduced motion. It’s an operating system level setting and websites and apps can actually respect it. The mobile side of things are better because they’re usually respected. On the web, it’s not as good because it’s respected only if the developer decides to implement this support for this setting, and usually they don’t. Nobody usually knows about this reduced motion. On your Android phone, you can find the setting from settings, and then it’s usually under Accessibility Settings, and then there is something like vision. On my phone it’s vision and then turn animations off, but it might be something else. Using your favorite search engine, put your phone and turn animations off, you will probably find the instructions for finding the setting.

From a development perspective, it’s respected in most of the cases. When it’s animator-based, then it’s respected. It doesn’t show the animation then, or if the app is built with Jetpack Compose version 1.2.0 or higher, then it’s respected. There are some times when you want to check if the setting is on programmatically or you know that it’s not respected automatically. You need to implement support. If you are using Compose version, that is lower than 1.2.0, then it’s not respected. If you are using something like Lottie to show the animation, I suggest checking or testing how it looks when the setting is on. To check it, look at the code. If reduced motion is enabled, first get the value of the animator duration scale from settings. Its value is a float and we can get it with Settings.Global.getFloat. Then add the context.contentResolver to it. What we get from there is Settings.Global.ANIMATOR_DURATION_SCALE. That is the piece of information that we want to know. If it’s implemented and the reduced motion is enabled, the value is zero. We try to get that float value. If there is a setting or setting not found exception, we catch that value and set the value to one because it can be any number that is not zero. If it’s not, the setting is not implemented, it’s not there, then we can safely assume that the reduced motion is not enabled. We have the animation duration. If the setting is there, it’s zero. If it’s there and it’s enabled, then it’s zero. If it’s not enabled, it’s something else than zero.