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:

• Support directional navigation
• Add descriptions to UI elements

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:

• android:nextFocusUp
• android:nextFocusDown
• android:nextFocusLeft
• android:nextFocusRight
• android:nextFocusForward

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:

<EditText
   android:id="@+id/title"
   android:layout_width="fill_parent"
   android:layout_height="wrap_content"
   android:hint="@string/title"
   android:nextFocusDown="@id/description"
   android:singleLine="true" />

<!-- ... -->

<EditText
   android:id="@+id/description"
   android:layout_width="fill_parent"
   android:layout_height="wrap_content"
   android:hint="@string/description"
   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:

<ImageButton
   android:id="@+id/btn_contact"
   android:layout_width="wrap_content"
   android:layout_height="wrap_content"
   android:contentDescription="@string/contact"
   android:src="@drawable/btn_contact" 
/>

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

ImageButton button = 
      (ImageButton)findViewById(R.id.btn_contact);
button.setContentDescription(getString(R.string.contact));

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.

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.

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.