Grokking Android

Getting Down to the Nitty Gritty of Android Development

Take These Steps to Make your Android App Accessible

By 7 Comments

Accessibility in an app helps users with disabilities to use your app with the help of the Android system. Android's accessibility system tools as well as third-party developer's tools provide features to help with visual impairment.

In this post I outline why you should care about accessibility and what steps to take to make your app accessible. I also deal with testing and why it's useful to care about accessibility up front.

Accessibility is a usability requirement

When it comes to planning a project, accessibility often is neglected or just mentioned briefly - without ever detailing what it means for the project at hand. That's odd. Why this neglect?

We agree that it's useful to make users aware of the flyover menu. Or to add hints to ease the discoverability of a bezel swipe. We sometimes go to great lengths to improve the usability of an app. But not when it comes to accessibility.

Of the many Android development books that I know, only two cover accessibility: Reto Meier's "Professional Android 4 Application Development" and Jasons Ostrander's "Android UI Fundamentals". That's a sorry state, in my opinion.

Accessibility is no after-thought

It is up to the designers and usability experts to work out the concept of the app - including everything that has to do with accessibility. Even though, as you have seen, it is pretty easy to implement, it is probably not so easy to get the concept right.

For example, users can change the font-size of their device. This can have a big influence of which design works and which doesn't.

With this in mind, you also have to decide what text shouldn't get scaled when this setting changes. And if there is a good reason for this. What would an unscaled text mean for people that need big text?

For example the stock email app does scale the text of the message list, but not of the folders. You have to decide thoroughly - and if possible test thoroughly - if and where this is appropriate.

Furthermore the size of clickable areas should be designed to be big enough for all kind of fingers and hit-precisions. Think of kids, of elder people, people with tremors and so on.

Think of people with color blindness. Do use clear contrasts and do not use colors only to signal the state of something. I am currently writing an app for a server monitoring service. Obviously red signals a critical situation whereas green is used for a properly functioning server. But we do not rely on color alone, but add text to distinguish both furthermore.

Then the order in which controls should be focusable has to be agreed upon right from the beginning. This is a minor change, but it's probably better not up to the developer's imagination.

Also you should plan on the labels for textual descriptions early on. You think thoroughly about any text displayed on the screen, so do the same for these descriptions. Otherwise you have to quickly come up with descriptions when you want to go live. Or - even worse - you might end up with the placeholders the developers used 😉

Finally do not forget to add feedback mechanisms beyond audio. No matter if people have hearing disabilities or not, you should always provide additional means to notify users. All users turn off audio in certain situations. So if you use a signal sound to alert a user of something, consider to also use haptic and visual feedback as well.

How to make your apps accessible

Gladly it is easy for most apps to make them accessible. Most often all you need to do is:

If you need controls not provided by the Android platform, you have to care about accessibility as well. Since I plan a mini-series about writing custom controls anyway, I will explain this as one part of this mini-series.

Support directional navigation

Users might find it easier to use the D-pad to navigate around your app. This is not only true for users with disabilities but might be more comfortable if users are distracted in some way or simply prefer this to touching depending on circumstances.

Without fine-tuning the navigational flow of controls, though, D-pad navigation might be cumbersome at some places.

Most often Android provides a reasonable navigational order. But if not or if you want to tweak it to improve upon this, you can do so by stating which element to focus next - for all four directions supported:

Of these only nextFocusForward might need some explaining. This denotes the element to focus when the user hits "next" on the soft keyboard or uses a gesture to move to the next focusable element.

The following snippet shows an example of how to do this:

   android:singleLine="true" />

<!-- ... -->

   android:nextFocusUp="@id/title" />

The target view must be focusable of course. All standard controls of android are focusable by default. But if you write your own custom-controls you have to take care of this yourself.

Add descriptions to UI elements

For some UI elements like image buttons and so on a screen reader is at a loss of what to read, if you do not help it. But helping is very easy to do. You just need to add a content description to these elements.

You can do so either when adding the views to the xml layout files:


Or you can add content descriptions programatically if they have to be dynamic:

ImageButton button = 

If a graphical element is used only to please the user visually without any further use, you should set the content description to "@null". That way screen readers know that they should ignore this element.

Test accessibility

To test the accessibility features of your app you need to test whether your changes work.

You can test the D-pad functionality easily in the emulator. You can either use the D-pad of the emulator or the arrow keys of your keyboard.

For testing that users with limited vision can handle your app, you can use TalkBack. This app is included on most android devices and can also be downloaded from the play store. Alas it is not included in the emulator. So you need to test on a real device.

Try your app without looking at the screen. Can you navigate around? Can you identify all elements and understand what they are used for?

You also have to test if your app looks reasonably good, if the user changes the default font-size. Especially activities with many views and relatively small UI elements might look bad with bigger text.

Don't forget to test the feedback mechanisms. Do they work without sound?

All in all testing accessibility should be based on the requirements outlined in the concept (see the section "Accessibility is no after-thought"). If the design of your app contains hints on what accessibility mechanisms to use, testing becomes straight-forward. Another reason why accessibility should be planned and described up front.

More on this topic

Google itself provides useful information about this topic in the training, developers and design sections of Android's site.

The design section contains a page on accessibility within its pattern section.

The developer section contains a very detailed article about implementing accessible apps as well as an accessibility checklist.

The training section contains the guide "Developing Accessible Applications".

And - oddly placed - the tools section has a nice document on accessibility testing.

TV Raman, an accessibility research scientist, blogs on Eyes-Free Android about accessibility features of Android. And he has uploaded many videos explaining Android's accessibility features to Youtube. He points out that these features are not only for visually-impaired people but might be useful in certain conditions for all of us.

There is also the Google IO talk on accessibility.

Finally for Nexus devices you can find the accessibility user guide on Google's support pages. For example, here's the accessibility guide for the Nexus 7.

Not covered in this post

As mentioned, I didn't cover adding accessibility features to your custom controls. This will be the topic of a post on its own.

I also didn't cover how to write accessibility services. These are tools, that give the user some kind of feedback on certain events. This could be reading out a text when the user navigates to an element using his D-pad or it might be some haptic feedback on a button press and so on. Google provides some tools as part of the Android platform, other vendors might add their own. The user can select which services to use in Android's settings. Google has a thorough guide on how to code an accessibility service.

Wrapping up

In this post I have outlined why you should care about accessibility and what steps to take, to make your app accessible.

I also covered that you should care about accessibility already while designing and drafting your app and how to test your app later on.

I mentioned hints on how to test accessibility and pointed out where to find more ressources.

So what's holding you back? Anything you miss to make your app accessible?

Note: I am no native speaker. So if anyone feels offended by any expression used here, please leave a comment on why this is and what other expression to use.

Disclaimer: Some of the links contained within this site have my Amazon referral ID, which provides me with a small commission for each sale. Thank you for your support.

Wolfram Rittmeyer lives in Germany and has been developing with Java for many years.

He has been interested in Android for quite a while and has been blogging about all kind of topics around Android.

You can find him on Google+ and Twitter.

7 thoughts on “Take These Steps to Make your Android App Accessible”

  1. Insetad of setting the contentDescription to null, the android:importantForAccessibility=”false” attribute should be used.

    1. Wolfram Rittmeyer

      You are right, Tom. Thanks for this addition. From Jelly Bean onwards you can use this attribute. But be careful: It is not available for older versions.

  2. Great post! Glad to see accessibility getting more coverage! The only thing I would add is to make sure your views have all the appropriate states (selected, focused, etc) defined. A lot of apps ignore those states since so few phones have d-pads.

    Thanks for the shoutout!

  3. I am trying to make my app launch with either shake gesture or volume button any help

  4. Hi Wolfram,

    Doing some spikes today with TalkBack enabled and **when navigating the Genymotion emulator by keyboard/physical phone/tablet with physical usb keyboard** I can’t seem to get it to read aloud the contents of TextView unless I mark them as `android:focusable=”true”`. In touch mode, this is not required – the service seems to read any TextView that you touch.

    This seems intuitive if you think about it for when TalkBack is enabled – how can Talkback know which element you want to read if you’re navigating with a keyboard, unless these elements are focusable.

    That said, I’ve not read any guidelines which tell devs to set focusable for TextView, in any accessibility article I’ve read so far (admittedly few). While this would seem to be a quick solution, it’s not ideal – consider keyboard/remote navigation on a TV app; probably don’t want every textview to be focusable? any thoughts?


    1. Indeed, Ataul. The guideline is to mark actionable items as focusable:

      “To ensure that users can navigate your application using only a directional controller, verify that all user interface (UI) input controls in your application can be reached and activated without using the touchscreen.” (

      I have not found any settings in TalkBack to change this default behaviour and to read everything on screen. Keep in mind: For this to work we would have to have a means to order elements meaningfully. We have that for focusable elements (e.g. nextFocusDown) but not for readable elements.

      Even though I consider this to be strange myself as well, I assume this to be the wanted behaviour. I assume that Google did it’s research and did talk with enough groups and people that rely on these features. TV Raman, the lead for accessibility features on Android, relies on these features himself. So I guess Google knows what it’s doing, even if for both of us this behaviour sounds odd.

  5. I guess it’s a case of adding accessible design where they can, and even Google treat it as an after thought; struggled to find any app that was navigable (even with sight!) just using keyboard.

    The Android TV emulator seems to do it in a more accessible way (but it is not the norm it seems) – if you go to the settings, you can see that only the right hand side is navigable using keyboard (the list items). If you enable TalkBack and try again, you’ll find that both sides are focusable, allowing you to focus on the TextViews that were previous not-focusable (the settings headers).

Leave a Reply

Your email address will not be published. Required fields are marked *