If you are reading this blog for the first time, you are probably a developer wondering how to make your app more accessible to screen reader users. This post explains how you can test your app for accessibility, what you can do to make it more usable by blind and visually impaired people, and where you can find more information to help you develop accessibly.
Understanding Android Accessibility
When developing for Android, you must keep three things in mind:1. The touchscreen is not accessible, so blind and visually impaired users find and activate controls using the d-pad or trackball.
2. Web views are not accessible, so blind and visually impaired users can not read information presented in this format, unless it is web content that can be accessed via the user default browser, in this case the Ideal Web Reader.
3. End users have very basic control over the information that is spoken, so long explanatory screens aren't helpful because the information generally cannot be repeated or spoken in its entirety.
Testing for Accessibility
To find out how accessible your app is for eyes-free users, simply turn on accessibility, activate a free screen reader, and try to use your own app without looking at the screen. Odds are you'll be sailing a stormy sea.To turn on accessibility, do the following:
1. From the Android Market, install a free screen reader. Current options are Talkback and Spiel. Choose one.
2. Go into Settings/Accessibility, and check Accessibility and your screen reader.
The phone should start talking within a second or two. If it doesn't, you may need to install a free TTS library like SVox Classic or ESpeak.
Developing with a Screen Reader in Mind
Google has published a set of best practices for designing for accessibility. These boil down to a few key concepts: • The UI should be navigable using a directional controller.
• Widgets should provide content descriptions.
• Custome views should deliver appropriate accessibility events during user interactions.
•
The list of suggestions below is based on issues end users encounter regularly:
1. Image-based controls should have appropriate content-descriptions; otherwise, eyes-free users hear "image button," without getting information about what the button is for.
2. All on-screen controls should be reachable via the trackball/d-pad or the Menu key; otherwise, eyes-free users cannot find or use them. This includes the Accept and Decline buttons of the initial screen.
3. Controls without implicit text (e.g., text inputs, radio buttons with separate labels, etc.) should also have contentDescriptions set; otherwise, eyes-free users can not complete complex input scenarios, as they will hear only "edit" or "checkbox," without having any information about how to populate the edit field or what checking or unchecking the box does. There is currently no way of associating static labels with inputs
. A workaround is to make the labels themselves focusable, but it's better to simply set the contentDescription of controls to the same value as the text that labels them.
4. Text alternatives should be available for information presented as embedded web views; otherwise, eyes-free users hear, "web view," and nothing else. Embedded web views are not spoken by the screen reader.
5. Apps that open the browser (to display a recipe, lyrics, shopping site, news article, etc) should open the user's default browser; otherwise, eyes-free users hear, "Web view," and nothing else. The stock browser is currently not accessible,, so blind and visually impaired users access the web via the Ideal Web Reader.
6. Explanitory text, like help screens and tutorials, should be short, no longer than the text displayed in the app description of the Market application on the phone; otherwise, eyes-free users do not hear them in their entirety. Two notepad apps that display text accessibly are uNote and OI Notepad.
Finding More Information
For more information, you can refer to a code lab created by some engineers on the eyes-free team. It goes over more advanced concepts. But this code lab is probably overkill for a developer who, like you, already has designed an app and just wants to make it accessible.For help with specific issues, you can post to a developer group for programmers with eyes-free accessibility in mind.
Checking an App's Accessibility Rating
To find out how accessible eyes-free users think your app is, visit the Android Access website and look your app up. The site is a venue for blind and visually impaired Android users to rate apps for general accessibility and to share tips and workarounds for problems, like unlabeled buttons or inaccessible features.To let end users know about your most recent accessibility improvements, post to the Eyes-Free users list or tweet @AccessAna, who will be happy to let other users know.
