Android accessibility: Tips and tricks

June 15, 2016

Introduction to Android accessibility and talkback

Ever tried to use your smartphone blindfolded? How would you approach it?

Even if not completely blind, many vision or hearing impaired users can’t interact with a smartphone as most people do. Both Android and iOS provide users with accessibility features and developers with accessibility frameworks to make things easier.

The available accessibility features vary on different devices and OS versions, some of the most common ones are:

  • Screen reader, to let non-sighted users interact with the device.
  • Big text, to increment the font size in all applications on the device.
  • Captions, to write on screen audio messages.
  • Color correction, to change displayed color palette to help color-blind users.

Some of those features don’t require any development effort, but some others like big text or the screen reader do. Unfortunately, mobile developers often don’t think about accessibility and don’t even know about the accessibility frameworks.

For the past 12 months I’ve been working on a massive mobile application. Eight months into the project, the requirement to support the Android screen reader, TalkBack, was introduced. In this post, I will give a brief overview of my experience with Android TalkBack and provide a few tips and tricks. If you’ve never worked with TalkBack before I would recommend Developing Accessible Applications on the Android Developers website for a quick start.

Spoiler: developing for accessibility is hard!

Talkback

TalkBack can be enabled on Android devices from Systems Settings > Accessibility > TalkBack. By default, the screen reading volume matches the device media volume. Once enabled, on most devices, it is possible to “pause” TalkBack by using an “L” gesture (down and right).

TalkBack reads the content of the screen to the user and allows them to interact with it using gestures. Each element on the screen should have a label, and the user can explore the screen in two ways:

  • Dragging their finger on the screen. As soon as the finger is sitting on an item with an attached label the screen reader will read it.
  • Swiping right, the user can move from element-to-element from the top left corner of the screen to the bottom right one. Swiping left allows the user to move in the opposite direction.

TalkBack is available as a standalone app on the Google PlayStore, but comes pre-installed on most Android devices.

It is worth mentioning that while TalkBack’s iOS equivalent, VoiceOver, provides similar functionality, the two are significantly different in how the user interacts with the system. So, if you’re working on both platforms be mindful of the different user expectations. And if you’re interested in accessibility on iOS have a look at this blog post.

Fragmentation

Android device fragmentation in 2013

Fragmentation is one of the major pain points of the Android ecosystem, when working on accessibility this problem is even more apparent. We’re all aware of how different OS versions and different vendor customisations result in different behaviours, as an additional variable different TalkBack versions influence the outcome as well. Vendors can also provide customised Text-To-Speech engines that replace the default TalkBack TTS engine.

Just to make a few examples:

  • On some devices, back navigation requires a double tap on the back button, on others it doesn’t.
  • Some devices will read “WA” as “Western Australia”, some others will read it as “W” “A”.
  • On some devices a floating action button is read in order considering its positioning on the screen, on some others it’s considered to be at the very end of the screen.

Settings

One of the first things to do if you’re working on accessibility is to explore the TalkBack settings, they can really make your life easier.

The most useful one is probably “Display speech output” under “Developer settings”. This setting displays on screen all the text read from the TTS engine. Turn it on immediately and mute the media volume if you want to retain your mental sanity while working with TalkBack.

Content description

While the system does a good job of creating labels for most UI elements like TextViews and Buttons, there’s not much it can do to automatically generate a label for an image. That’s why the contentDescription attribute should always be provided as a best practice, and should describe the image well enough to convey to a non sighted user the same message that the image is conveying to a sighted user. Unfortunately most developers do not bother providing a contentDescription attribute for ImageViews in their XML layouts.

Support library

Using UI components from the latest Support and Design Library from Google [4] (at the time of this writing 23.4.0) can lead to some easy wins and avoid you some headaches. Google is constantly improving and fixing accessibility bugs on the Support Library UI components.

Important for accessibility

You may have some elements in your UI that are not adding any value to a non sighted user. From API 16 you can mark any View as not important for accessibility, TalkBack will then completely ignore that View.

One thing to be mindful of when using the importantForAccessibility attribute (or method) is that this View is going to completely ignore any accessibility related events. This is evident on ListViews for example, where setting the ListView as not important for accessibility will prevent it from scrolling when the user reaches the end of the page by right-swiping.

Tip: Pay attention to the value IMPORTANT_FOR_ACCESSIBILITY_NO_HIDE_DESCENDANTS. It was added later on in API 19, and will be ignored by previous APIs.

Dynamic UI changes

Take into consideration that all dynamic UI changes like inline error messages, loading indicators or content refreshing are not useful to a non sighted user, and should be accompanied by voice announcements.

Announcements are triggered simply by calling announceForAccessibility on a View object:

mLoadingIndicator.announceForAccessibility(“Loading in progress”);

Custom layouts

Sometimes a custom UI element or an entire screen might not meet a reasonable level of accessibility, no matter how much work you put into it. In these cases it’s probably easier to rethink how the user interacts with the element and design a new layout just for accessibility users.

It’s easy enough to determine if TalkBack is on at runtime, by using the following snippet:

AccessibilityManager am = (AccessibilityManager)                                            mActivity.getSystemService(Activity.ACCESSIBILITY_SERVICE);boolean enabled =  am.isEnabled();

If accessibility is turned on we can display our custom UI element or layout.

Build Accessibility as you go

The best suggestion I can give you is to build accessibility as you go. Don’t leave it as an add-on for a later stage, you’ll probably regret it, especially if you have complex layouts. This is for two main reasons:

  • While you’re working on a feature you’ve already got the context you need to make it accessible. Going back to it in the future could result in more time and effort required.
  • When you make changes to a feature to make it accessible you then need to test the feature in its entirety, potentially doubling up on QA effort.

Android Accessibility Scanner

Last but not least, when you’ve finished implementing accessibility on your app, you can use the Accessibility Scanner provided by Google to verify if there are some areas of improvement you should focus on. The Accessibility Scanner analyses the screens of your app to identify potential accessibility issues. Just install the app, follow the onboarding tutorial to enable the scanner, launch the app you want to test and start the scanner.

You’ll get some accurate suggestions on how to improve accessibility in your app.

Screenshots of Google Accessibility Scanner in actionScreenshots of Google Accessibility Scanner in actionScreenshots of Google Accessibility Scanner in action

Conclusion

Supporting TalkBack and other accessibility features can be time consuming, but it’s definitely worth doing. Keep in mind that the sooner you start the easier it is, and remember to test your app’s accessibility support on multiple devices!

If you want to know more about Android accessibility features I can recommend this session from Google I/O 2016.

 


 

References

  1. Google PlayStore – TalkBack
  2. Android Developers – Developing Accessible Applications
  3. Google PlayStore – Accessibility Scanner
  4. Android Developers – Support Library
  5. Android Developers – View#importantForAccessibility
  6. iOS Accessibility: A Brief Introduction
  7. Youtube – What’s New In Android Accessibility

 


 

Author: Kamal Kamal Mohamed, Software Engineer - Android

Android Accessibility