Lately, I've been learning about Wear OS development. As I'm also an accessibility specialist, I've naturally also been looking into the accessibility aspects of Wear OS. The small form factor impacts many things typically associated with accessibility. Not everything can work, or is working, the same as with, for example, phones and tablets.
It's been fascinating to dive into the topic and learn more about it. In this blog post, I'll give pointers on Wear OS accessibility and share some of the learnings I've had. For transparency, I must note that my perspective is very Pixel-y, as I have a Pixel Watch 3.
Let's dive in!
Screen Reader Seems to Be on the Main Stage
Most of the available documentation about Wear OS accessibility focuses on making apps accessible for screen reader users. The Accessibility on Wear OS-page first mentions font size and rotary input (which we'll discuss later in this blog post), and then proceeds to optimizing apps for TalkBack (the built-in screen reader), which takes up most of the page.
And I'm not surprised - that's the case with most of the accessibility documentation for any platform. And don't get me wrong, screen reader accessibility is important, but there's often this misconception that that's all accessibility is. However, it's not just screen readers - there are many other sides to it.
In Wear OS's case, however, I think that it might even be warranted to keep the screen reader accessibility on the main stage of the accessibility documentation. The reason for that is that many other things work out of the box. I mean, of course, there are ways to make them not work, but unless you're misusing components, most of the things work.
The "Optimize your app for Talkback" section in the forementioned documentation comes down to basics:
- Use built-in components, as they already have the semantics, accessibility actions, focus handling, etc. included.
- Add content descriptions to tiles and complications.
- Tip! If you're wondering what to write in a content description field, or if the element even needs one, I've written a guide: How to Add Content Descriptions in Compose - A Guide for Android Devs
- Understand list behaviours, so that you can build the app in a way that supports Talkback.
I recommend checking out the further details from the Accessibility on Wear OS-page!
Small Screen Size
As mentioned, small screen size brings its own accessibility (and usability) concerns. There's not much space for elements on the screen, so many of the usual design patterns for, e.g., phone apps don't work.
One cognitive accessibility-related concern is the use of icon buttons. And more specifically, icon buttons without labels. When the screen estate gets smaller, the number of labelless icon buttons usually increases.
Why is it a problem? Well, icons are not universal. It's not always easy to understand what each icon communicates and what action the button performs if there is no label attached to explain it. And if you have, for example, some cognitive disability, or are just stressed, it might even make things worse.
I personally hate icon buttons, because I rarely know what each of them does. I don't learn them, and I also hate the idea that I need to test what they do to know what they do. What if I accidentally delete some important data? Or call someone? The latter is probably my worst nightmare.
And yet, at the same time, I do understand that the small screen size requires some compromises on this front.
Font Size Considerations
Then there are the font size considerations - your app needs to support user's preferred font size. This support may require you to adjust the design of your app to accommodate the larger font sizes better.
The Wear OS accessibility page also mentions the following:
Use an ellipsis to show that text overflows its container.
I disagree with this to some extent. Truncating texts can be a huge accessibility (and usability) barrier. If you're interested in why, I've written a blog post about it: The Problem of Trun... So, my suggestion would be to think about whether the design could be changed to allow text to reflow if it doesn't fit the container.
Minimum Touch Target Size
Continuing from the previous section, as the watch screen is small, the importance of conforming to minimum touch target sizes with clickable items is even more important. And at the same time, it's tempting to reduce the clickable size to save screen space.
The minimum touch target size requirement, as per Android Material Design, is 48 x 48 dp. However, for Wear OS and small screen sizes, some situations allow a 40 x 40 dp size. The accessibility documentation does not specify these situations.
If you're using the built-in Material components, then you should be fine on this requirement. They have enough padding for clickable items to fill the touch target size needs.
Different Input types
Of course, as a medium, and due to its small screen size, a watch differs in input compared to, for example, a phone. I'll discuss two input types next: The text and rotary input.
Text Input
Inputting text on a small device presents some challenges. Luckily, Wear OS supports multiple ways of inputting text (and other data) to your app. Remote Input is the technical solution for this, and as Create input method editors on Wear lists, these options include:
- Dictation
- Emoji
- Canned responses
- Smart Reply
- Default IME
The default keyboard has tiny characters (because of, you guessed it, the space constraints), so I personally like to use dictation way more. It's surprisingly good with Finnish, but with English, I apparently pronounce words in a way that it takes several attempts to get them right.
From an accessibility perspective, it's important to support different ways of inputting text. Someone might not be able to hit the keys on the keyboard, and someone might not be able to dictate, so supporting both makes the app more inclusive for users.
Rotary Input
The Wear OS Accessibility documentation explains the rotary input:
Most Wear OS devices contain a physical rotating side button (RSB), rotating bezel or touch bezel. This is called a rotary input. You can use the rotary input to adjust the volume of media apps, scroll content up or down, and more.
Wear OS devices are smaller than mobile devices, which presents additional challenges. Users with dexterity challenges may find accuracy on a small screen difficult. Screen reader users may also find it difficult to use two-finger interactions for scrolling. Using rotary input assists users with these challenges by providing a more convenient way to scroll rather than using the two-finger interaction.
In short, from the accessibility perspective, supporting Rotary input is essential. The Rotary input with Compose page explains how you can do that, so I'm not covering it here.
Reduce Animations
You know, the first thing I do when I get a new device is check for the reduce/remove animations or reduce motion setting, as I severely need it. I was happy to find it on my watch and turned it on. And after a while, I was surprised - I don't really need this setting on a watch as the animations that size don't trigger my symptoms.
But others benefit from this setting, so you want to support it. Luckily, if you're using the built-in components and animation APIs, then they take care of supporting the Reduce animations setting as well.
However, if you're building something customized, or get a bug ticket from someone saying your app doesn't respect the setting, here's how you can read the value of the setting and then adjust your code according to it:
val isReduceMotionOn = LocalReduceMotion.current
And that's it. I wish it were as simple on phones, and this Composition Local would also be available for larger Android devices (than watches).
Curious why the reduce motion (or, remove animations) setting is important for someone? A couple of years back, I wrote a blog post about motion sensitivity and how to support the remove animations setting on Android: Android, Animations and Reduced Motion
Magnification
Wear OS also provides a pretty neat magnification tool. While it's not something you'd probably need to support in your app code, it's useful to know it exists. You can turn it on from the accessibility settings of the watch.
With it, the same considerations apply as with the magnification on larger devices. These concerns mean, for example, having good enough color contrasts, not relying on touch-input only, keeping text field and other interactive element labels close to each other, and using graphics that don't pixelate too much when zoomed in.
Wrapping Up
So, in this blog post I've discussed different accessibility considerations for Wear OS apps. I've discussed screen reader support, small screen sizes, font size considerations, minimum touch target size, supporting different input types, the reduce animations setting, and magnification.
Were these all familiar to you, or did you learn something new?
Top comments (2)
This apply for both square and round wearos smartwatches? are there unique variables for the square and round layouts?
The documentation doesn't actually separate the shape of the screen, so generally, this does apply for both. Of course, a round and a square watch are different shapes, so it affects, for example, the scaling of components when scrolling a bit, so some apps might have to consider this.