As a senior developer, I have worked in a number of projects and, unfortunately, in nearly as many the team has not taken Android accessibility into account at all. Soon a large number of organizations are forced to, however: on the 23rd of June, 2021 the EU’s Accessibility Directive will come into effect. This directive is made to ensure the equal treatment of EU’s citizens and that is why it will target all public sector mobile services. In addition, the directive also affects certain big private mobile service providers, like banks and insurance companies. In practice, this means that these industries need to have their mobile applications accessible also to users that have motor or sensory impairments.

I will give you the first developer’s tips to improve your accessibility in Android applications in this short article.

1. My Own Pet Peeve and the Motivation for This Article: The Missing Button Description!

Accessibility is a benefit to the end-user whether they have particular challenges with software and smart devices or not. Personally, I constantly find icons in new apps that have a completely unknown use for me.

Ideally, a long press of the button momentarily displays a text element which describes to me what happens if I press the icon. In the real world, however, I will find that the icon is simply left there without the text. When this is the case, I can only test my luck and try out blindly what the icon actually does…

Fortunately, the problem can be easily solved: just make sure that the menu element’s child item element has the attribute android:text and that it has an apt description.

An even better solution, if the specifications for the UI allow it, is to set the attribute app:showAsAction=”ifRoom|withText”. Don’t forget about the android:titleCondensed attribute that you can use to display a shorter description. As an example, consider the descriptions “Select” and “Select all” – which one do you think is more descriptive when the context is that of a word processing application?

Take note that this only scratches the surface of everything that proper accessibility is able to accomplish in applications. Small changes like this one can have a huge impact for all users!

2. Image Content Descriptions

Next on the list, you can go through your app’s images: do they have an android:contentDescription attribute? This seems to be constantly forgotten by developers and might also sometimes go through code reviews unnoticed. Screen readers use ContentDescription to tell the user what the image is about, similar to how the alt-tag works in web development.

Of course, some images can be completely decorative and in these cases you can set the content’s description value as @null so that screen readers know to skip this element. Note that even though many screen readers already do this, you should still set the value to follow the best practices.

Let’s take a person’s profile picture as a practical example. Do not merely set the description as “a person’s profile picture” in your XML. Of course, you can also automate these descriptions and be able to get a bit better descriptive texts like this:

imageView.contentDescription = user.fullName + " profile image"

3. Static analysis with lint

While the above examples are a good place to start, how can you make sure that you haven’t forgotten about anything? Manual testing with screen reading software and different navigation tools should be done before release, at the latest. While you’re doing that, you should also adopt static analysis with lint. You can quickly get a comprehensive HTML report about your app and start fixing problems one by one by running the ./gradlew lint command. Of course, you can also set custom rules for your lint check-up meaning that your programming environment would start complaining about potential problems as the code is being created. In the CI pipeline, these can stop the code from being merged with the main branch in your version control system.

Closing words about Android Accessibility

I hope these examples will help you in your first steps on the road to improving Android accessibility. There are many more examples, instructions, and practices than it’s suitable to present in a single article or that the author is even aware of. With this blog post, I wanted to help you understand that everyone benefits from accessibility and it does not, in practice, increase the workload of the developer by much.

As a developer, it is your responsibility to implement accessibility into your application. Does the UI sketch you received seem to be too complex? It probably is, demand that it’s replaced with a more accessible version! Is the product owner pushing schedules and asking you to cut corners? Push back and let your application be accessible to everyone!