Android for Everyone: Part 3— Implementing Your Android App for Accessibility
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.
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
Our next screen is the main screen, where the existing favourite cats are displayed. There is also a floating action button or FAB which allows the user to add new favourite cats.
This is how we normally implement this: we have a layout with the all the favourite cat images in, and a FAB button at the bottom. But, when TalkBack reads the screen, it will laboriously read through all the existing cat’s descriptions and eventually the new favourite button. What if we first want to allow the user to add a new favourite?
Traversal order
Well, we can use the attribute accessibilityTraversalBefore on the FAB and set it to what it must come before — the existing favourite cats. This layout will first read “New favourite button, double to activate”, and then after a user swipes right, it will read the existing favourites’ descriptions.
Announce for accessibility
What if something changes on the screen? How do we notify the TalkBack user that something changed? We can use the announceForAccessibility function. In this code example, when the FAB is clicked, it will add a random new favourite cat (this is an example app after all), and then say “Added new favourite”. By the way, toasts are also announced but note that it’s for both accessibility and non-accessibility users.
Accessibility delegates
My last coding tip is about changing the default “Double-tap to activate” announcement on controls. Say I wanted TalkBack to say “New favourite button, double-tap to add new SparkCat” instead?
So all this overcomplicated piece of code does is replace the default description activate with add new SparkCat.
Accessibility on Android is a complicated matter, but with these few tips, you’ll get most of the way. Something I haven’t spoken about is making custom views accessible — but that’s a whole talk on its own.
In the next article, I will be exploring how Android developers can test for accessibility using some very cool tools.
Till next time!
References
Android Accessibility Tutorial: Getting Started by Victoria Gonda
Easy Android Accessibility: Android Conference Talks
What’s Next? A Practical Introduction to Accessibility on Android by Ataul Munim
