Accessibility insights. How to make the most of Android’s accessibility features.

Note : Accessibility (often abbreviated to A11y — as in, “a”, then 11 characters, and then “y”)

Improving your product’s a11y can enhance the usability for all users, including those with low vision, blindness, hearing impairments, cognitive impairments, motor impairments or situational disabilities (such as a broken arm).

You may have experienced difficulties using your phone while wearing gloves when it’s cold outside. Maybe you’ve had a hard time distinguishing items on the screen when it’s bright outside. Most people will have at least a short term disability at some time that makes it difficult to use their mobile device. This includes someone who was born blind, or lost fine motor skills in an accident.

With so much of the population experiencing decreased vision, hearing, mobility, and cognitive function, you should do your best to give everyone the best experience in your apps.

In this write up, we are going to discuss ways we can make Android app more accessible, and by the end of this you will know the most basic ways you can improve your app for a11y. You will learn:

• Available a11y tools people are using.
• How to discover existing a11y issues, and prevent a11y regression.
• Android attributes you can use to make your app more accessible.
• Design guidelines to allow your user to use your app with ease.

A11y tools :

Assistive technology helps increase, maintain, or improve the functional capabilities of individuals with disabilities, through devices like screen readers, magnification tools, and hearing aids.
There are many tools that people use to interact with their Android devices. This includes TalkBack, Magnification, and Switch Access, to name a few.

TalkBack allows you to explore the view using gestures, while also audibly describing what’s on the screen.

Magnification allows you to zoom in on parts of the screen.
Both TalkBack and Magnification are helpful for people with limited visibility.

People with limited mobility can use Switch Access to allow them to navigate without using the touch screen.

Here I am going to talk mainly about TalkBack, as it incorporates both screen traversal for navigation and screen reading to understand what is in focus. You can enable all the a11y tools the same way as you will turn on TalkBack.

To turn on TalkBack, go to Settings on your Android device. Then find Accessibility/TalkBack, and toggle the tool on.

pic 1

Testing tools :

While using TalkBack and other a11y tools we can identify a11y issues manually, there are a couple other testing tools provided for developers to help identify a11y issues.

Lint :
Android Studio shows lint warnings for various a11y issues and provides links to the places in the source code containing these issues. In the following example, an image is missing a contentDescription attribute. The missing content description results in the following message:

pic 2

If users of a11y services, such as screen readers, encountered this image within the app itself, they wouldn't be able to understand the image's meaning.

Automated testing :
The Android platform supports several testing frameworks, including Espresso and Robolectric, which each allow you to create and run automated tests that evaluate the a11y of your app. However this functionality has been removed in Robolectric 4.5. Use Espresso or the Accessibility Scanner app instead.

To see a video overview of a11y testing with Espresso and Robolectric, watch the following video from minute 31:54 to 34:19: Inclusive design and testing: Making your app more accessible — Google I/O 2016.

Espresso tests
For more in depth checks, you can turn on checks in your Espresso tests. Do this by adding the following line to your test or test runner.

AccessibilityChecks.enable()

Check the Google docs for how you can further configure these tests.

Accessibility Scanner
Google also gives us an Accessibility Scanner that you can download from the Play Store. After downloading, the scanner can be turned on in the same Accessibility settings menu you were in before to turn on TalkBack. Navigate to Settings/Accessibility/Accessibility Scanner, and toggle it on.

pic 3

Once turned on, navigate to the screen you want to scan, tap the check mark in the blue circle. Wait a moment for the results of the scan to show.

pic 4

The results will show the scanned screen with orange boxes around any issues it found. By clicking on any of these boxes, you’ll get the description of what was found to be wrong, and a suggestion for how to fix it.

pic 5

Now that we know how to find a11y issues, let us look into the ways of fixing them, and making the world a better place!

Accessibility Attributes :

Content description (android:contentDescription )
contentDescription is a small bit of text that describes the view. You don’t need to specify the type of view in your description. This is already inferred by the screen reader, and it will announce it on its own.

Adding a content description is something you should do for every image or button that does not otherwise have text for the screen reader to read. If the element is not important to understand what is on the screen, the contentDescription can be set to @null. If you do this, TalkBack, and other screen readers will skip the element entirely, and move onto the next thing in the view.

Another attribute you can use to tell the screen reader to skip the view element is android:isImportantForAccessibility. When set to ”no”, the screen reader will skip this element while traversing the view.

Grouping ( android:focusable ,android:focusableInTouchMode )
To specify that child elements should be in focus at the same time, add the android:focusable attribute with the value ”true” to the parent element of the two. Also add the attribute android:focusableInTouchMode with the value ”false”, as you only want this to be focusable for the screen reader.

Consider the below example to understand more on grouping,

pic 6

TalkBack traverses through everything on the screen, in order of the file. This can make some core actions, like editing the cups ‘Coffee Limit’ value, harder to reach. There are other things, like label/value pairs, that require extra steps to get all the information when they should be grouped together. You should make sure everything on the screen is reached in a logical order, and grouped in a way that makes sense.

There are attributes you can use to improve these issues. Start with the “Amount Consumed” label, and the associated value. These are both parts of the same piece of information, and should be grouped together instead of requiring you to traverse each one separately. So this can be done by using android:focusable ,android:focusableInTouchMode attributes as shown below.

<LinearLayout
        android:id="@+id/consumedContainer"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:orientation="horizontal"
        android:focusable="true"
        android:focusableInTouchMode="false">
          <TextView
          android:layout_width="wrap_content"
          android:layout_height="wrap_content"
          android:layout_weight="1"
          android:text="@string/amount_consumed" />
          <TextView
          android:id="@+id/amountConsumed"
          android:layout_width="wrap_content"
          android:layout_height="wrap_content"
          android:layout_gravity="end"
          android:layout_weight="1"
          android:textAlignment="textEnd"
          tools:text="0 of 5"/>
</LinearLayout>

Labels (android:labelFor)
‘Grouping attributes’ discussed above solved the grouping problem for the consumption, but we have a similar issue for “Coffee Limit”. The label is read separately from the editable value, with nothing linking the two. This will use a different solution than we used for the amount consumed. The EditText still needs to be individually focusable to change the value. Add the android:labelFor attribute to the “Coffee Limit” TextView, with a value of the id of the EditText value, coffeeLimitValue.

<LinearLayout
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:orientation="horizontal">
<TextView
          android:id="@+id/coffeeLimitLabel"
          android:layout_width="wrap_content"
          android:layout_height="wrap_content"
          android:layout_gravity="start|center_vertical"
          android:layout_weight="1"
          android:labelFor="@id/coffeeLimitValue"
          android:text="@string/coffee_limit_label"/>
      <LinearLayout
          android:layout_width="0px"
          android:layout_height="0px"
          android:focusable="true"
          android:focusableInTouchMode="true"/>
      <EditText
          android:id="@+id/coffeeLimitValue"
          android:layout_width="wrap_content"
          android:layout_height="wrap_content"
          android:layout_gravity="end"
          android:layout_weight="1"
          android:hint="@string/coffee_limit_input_hint"
          android:inputType="number"
          android:text="@string/default_coffee_limit"
          android:textAlignment="textEnd"/>
</LinearLayout>

Now when the EditText with the value for the limit is selected, talk back audio includes the text of the coffeeLimitLabel TextView. This provides the user context about what the editable value is for, relating it to the previous element. Use labelFor whenever you have a situation where you have a label and a value that should be individually focusable, but are referring to the same thing.

Traversal order (android:accessibilityTraversalBefore)
You can use android:accessibilityTraversalBefore on a view to specify what item this should come before by using the id of the targeted view.

Note: accessibilityTraversalBefore is only available on Lollipop and higher, and will only work if the element whose id you provided is focusable.

Designing for accessibility :

There are things we can build into the design of apps to make it easier for all your users to use. Size, colors, and layouts are all things we can be considerate of.

Touch targets
It’s recommended by Google to make any clickable items at least 48dp in size. That is because anything smaller is difficult for people with vision and motor impairments to tap accurately. In addition, you’ll help out all your users that might be in a bumpy vehicle, wearing gloves, or in bright light that makes it hard to see the screen. Everyone benefits from making this improvement.

To solve this, add the android:minHeight attribute to EditText. Make sure the value is at least 48dp. Alternatively, you could set android:height to 48dp or higher.

Color contrast
Having low vision, color blindness, or a dimmed screen can make it difficult to read text with a low color contrast.
The recommended contrast ratio for text this size is at least 3.0 to 1.

Depending on where this is in your app, there are multiple possible actions you can take. You can change the font color. You can also change the background color.

Now you know how to use TalkBack and the Accessibility Scanner to identify a11y issues in your app. You also know that you can use Espresso and Lint to catch and make sure issues don’t creep in.

Through using the Accessibility Scanner and TalkBack, you can identify areas of the app that could use a11y improvements. You can use contentDescription, isImportantForAccessibility, focusable, accessibilityTraversalBefore to give the user the right information at the right time when using a screen reader.

You also know some tips for creating accessible designs. Making sure touch targets are big enough, and you have a high enough color contrast will benefit all users.

These are some of the main things you can do to make your app accessible, but there are also many more things. Make sure to go through Google’s accessibility checklist when creating your app. You’ll find things you learned here, as well ways to get started making even more improvements.

Thanks to Sree Kumar A.V, Caren Chang and Enrique López-Mañas for reviewing the article and providing some insights.

Thanks for reading, happy coding!!