Photo by Safar Safarov on Unsplash

Part 1 — Android & Accessibility

Part 2 — Designing Your Android App for Accessibility

Part 3 — Implementing Your Android App for Accessibility

Part 4 — Testing Your Android App for Accessibility

This article series is for developers and designers interested in learning more about accessibility, particularly related to the Android platform.

The first article in the series aimed to clarify what accessibility is and which services the Android platform provides to make Android a platform for everyone. The second article sought to explain the fundamental design principles for designers to make their work more accessible to a broader audience. The third article educates developers on a few simple implementation details to consider when coding their Android apps. The fourth article will introduce several tools that assist in testing the accessibility of apps.

Coding for Accessibility

How can tools like TalkBack be used with our app? Our user needs to be able to view the app, and also interact with the app. But, does that mean that we have to write special integrations for each kind of accessibility service out there? No, the Android Framework does all the heavy lifting for us, providing the necessary integrations with the service. Mostly, all our app needs to do is a few tweaks here and there to accurately present information to our user. Let’s have a look at the most common ones.

Content descriptions

So the one thing most people know about accessibility is that they should provide alternative text, called a content description on Android, whenever they have an image. This little code snippet shows how we’d label a star image using the contentDescription attribute.

But it’s actually not necessary to label every image. Some images are purely decorative. In that case, we can set the contentDescription attribute to @null, to get rid of that pesky warning in Android Studio.

Or even more explicitly, we can set the importantForAccessibility attribute to no. I like this a bit better, it’s more clear about our intentions.

Sample app

I created an app called SparkCats for the rest of the examples. It’s basically a dating app for cats.

Profile screen

The first screen I want to show you is an individual cat’s profile screen. Notice that we have a label name at the top, followed by the cat’s name, Eliza.

SparkCats profile screen

This is how we would ordinarily implement this (of course, I would externalise the strings). We’d have two TextViews, one for the name label and one for the cat’s name. But the problem is, it’s not entirely accessible. A TalkBack user would hear “Name”, and would then have to swipe right to hear “Eliza”. How do we fix this so that they are read together?

Grouping

The one option is grouping the two TextViews into a new parent layout, and then set two attributes on it: focusable to true and focusableInTouchMode to false. The first attribute will ensure the label and cat’s name are read together, without swiping. The second attribute will ensure that these elements aren’t focusable to non-accessibility users.

Labels

Another option for very specific use cases is to use labels. It doesn’t need an extra parent layout to group the elements, which is nice. Instead, we set the attribute labelFor to the cat’s name TextView.

Home screen

SparkCats home screen