Leveraging Android Framework for Accessibility

If you provide a useful service, why limit who can receive it?

If you’re building an app, it’s not enough that you’re the only one that can use it. We have to be open to making our apps accessible to anyone regardless of how they interact with their device. This could be developing for a multitude of screen sizes, filling in that contentDescription that your ImageView demands or even considering the colour palette you’re using in your app.

Now from a realist’s perspective, it’s not just a moral obligation to be inclusive of all but also a fantastic business opportunity. The purple pound for our industry is worth 17.1b pounds. That’s the spending power of the disabled here in the UK alone. Making your app accessible significantly increases profit margins.

Finally, if that didn’t make you want this enough — legislation was published in 2018 which makes it a legal requirement for any website or mobile application to be fully accessible before going live. The accessibility regulations aim to help make sure online public services are accessible to all users, including disabled people which makes this pretty serious stuff.

Types of Accessibility

We typically break down accessibility in Android development into different categories, now it’s not about categorizing people but more about finding a solution for a common problem and let's face it. We all age, that being said it’s likely that one of the following accessibility categories will impact even you the reader at some point in your life:

• Deafness and hard of hearing
• Motor impairments
• Cognitive disabilities
• Blindness & Visual Impairments.

In this article, I hope to provide you with some in-depth knowledge so that we can together create a more inclusive future for Android app development.

— Let's jump into it!

Talkback

Talkback is a Google screen reader for Android devices. It does a lot of work for us under the hood translating what we build in our views in different ways. Let's explore those:

• Speech — The Talkback application will announce ques to the user to indicate what is within a view.
• Braille — An external braille machine can be connected and used via Bluetooth. Using this the user can feel what is on screen.
• Switches —Switches can be connected by Bluetooth and may be useful for people who may have difficulty performing forced actions such as swipes in your app.

Now the Android Framework is what translates to Talkback what is on the page but developers have to have knowledge on Talkback to effectively leverage its functionality. In the next section, let's look into this.

Accessibility Scanner

Let’s investigate these issues using the Accessibility Scanner app on Google Play. Accessibility Scanner is an app developed by Google in order to point out simple accessibility issues within your application. The downfall however is that if your element hints and image descriptions don’t make sense, the app cannot tell you to re-word your title and description. It will always be recommended to get real users to give constructive feedback to help improve those issues. That being said, it’s still a useful tool to run on your feature before merging to the master branch.

You can head on over to the play store to follow along with these examples if you like. You can download the app here. You’ll also need the DEMO application.

Let’s have a look at the top 3 issues I came across running the scanner on the DEMO application.

Text Contrast

This is huge. We need to have text that is easy to read. Sometimes to your own eyes, it can look perfect. It can get to a point where we stand back from our chair and marvel at our newly created layout. We almost brag about it with a fiery passion in our heart… but not everyone can see what you can see? How then do we create that view for everyone to have that same fiery passion? We must first consider the common types of visual impairments; Loss of Central Vision, Loss of Peripheral (Side) Vision, Blurred Vision, Extreme Light Sensitivity & Night Blindness allowing them to influence our design.

We do that by creating themes in our Android application, leveraging the colour contrast ratio all while bearing in mind our design decisions. Let’s look at the colour contrast first. In WCAG 2, contrast is a measure of the difference in perceived “luminance” or brightness between two colours (the phrase “colour contrast” is never used). This brightness difference is expressed as a ratio ranging from 1:1 (e.g. white on white) to 21:1 (e.g., black on a white). To give a frame of reference, on a white background:

• Pure red (#FF0000) has a ratio of 4:1.
• Pure green (#00FF00) has a very low ratio of 1.4:1.
• Pure blue (#000FF) has a contrast ratio of 8.6:1.

WebAIM has a great contrast checker. Check out that here to ensure your app colours have the right contrast ratio. WebAIM also has an API that we can use to change the colours for our users on the fly and get a JSON response by calling the URL below. This really helps as we get a pass or fail for the different sizes of our text. This could be useful if you needed to change colours dynamically for someone who is colour blind towards a certain colour your app prominently uses.

Google recommends that a minimum contrast ratio should be 4.5:1 for all text, however, a 3.0:1 is considered acceptable for large or bolded text. This is a great step in the right direction. We have a guide to tell us if our text is accessible or not based on colour and size.

You can see below an example of poor contrast as the scanner shows us a yellow circle where the issue is. The App is even kind enough to suggest improvements upon clicking the yellow circle. This screen will allow you to play around with colours until you find the perfect colour contrast.

What we could do now that we have found our styles are not accessible is change our styles either by creating a new style or extending and customing a style that has the new properties set so they can be re-used throughout your app to create a consistent and accessible user interface for the visually impaired. You can also create a theme changing the colours for your entire app super easily.

Item label

As Talkback announces the ques to a user it may come to a point where Talkback cannot probably announce ques due to the way we have designed our app. It could even be that we have not included core XML in our layout to leverage the Talkback functionality.

The screenshot below is showing the Accessibility Scanner circling an area we may not have a label for. So what can we do about this?

Hints — In our edit text views we can use the property hint which is used commonly to give an example of input. What if I told you that hint was extremely important to your accessibility? You can either enter a logically worded hint. In the example below, we have this stored in a values xml.

We can also decide to add a text view and use the labelfor xml property to connect a text view to an edit text field. This edit text field will then use the text view as a label and will be read out the label first in the right order for Talkback. An example is shown here.

Note — If a user has entered text in the editable field, the screen reader speaks the text in place of the label.

Labels — Much like the web version of an alt attribute xml property contentDescription is used to describe our images. We should add this to our imageViews. We can use this to tell the user something logical about the image.

• What is it?
• What will clicking it do?
• Why is it there?

Note — Decorative images or images that don’t convey meaningful information graphically do not require content labels. In these cases, set an android:contentDescription attribute of "@null" or an android:importantForAccessibility attribute of "no".

Touch Target

The third and final issue I would like to discuss is the touch target. You can think of this as like a ‘hit box’ in a game. If the view such as an image or button is too small to click this will throw a touch target accessibility issue within the accessibility scanner.

We can see from the screenshot below that we have a small image and the scanner suggestion is that we increase the image to be 4x the size. I imagine this would create all kinds of design issues however there are different ways of solving this issue.

Padding — We can add padding around the image to make the hitbox larger. This is a brilliant idea as it will not distort the image in any way.

minWidth and minHeight — attributes can also be used however these attributes will distort the image and may cause problems for your design.

After updating the size of the image in your layout your app will immediately become that little bit more user friendly for people with motor impairments.

In Summary

• Let's make our apps available for everyone
• Test with Accessibility Scanner when writing new features
• ‘hints’ and ‘contentDescription’ attributes are used to describe the content
• Use the Contrast Ratio model to ensure the foreground and background colours are clearly distinguishable
• ‘Themes’ and ‘Styles’ encourage consistency
• Use larger ‘touch targets’ for the Motor Impaired users
• Always prioritise user feedback.

I hope to have encouraged you to consider accessibility in your app. If you would like to hear more about this give me a few claps. 👍

Further Reading:

• Principles for improving app-accessibility #
• Test your app’s accessibility #
• Material Design — Accessibility #