Designing for Accessibility
Many Android users have disabilities that cause them to interact with their Android devices in different ways. These include users who have visual, physical or aging-related disabilities that prevent them from fully using or seeing a touch screen.
Android provides an accessibility layer that helps these users navigate their Android devices more easily. These services provide things like text-to-speech, haptic feedback and trackball/D-pad navigation that augment the user experience.
Your application should follow these guidelines to assure that it will provide a good experience for these users.
Following these two basic rules will solve the majority of access related problems:
- Make all of your controls accessible via the trackball or directional controller.
- ImageButtons, EditTexts and other input elements using the contentDescription attribute.
Allow Navigation with a Directional Controller
Many Android devices come with some sort of directional controller, such as:
- A clickable trackball that can be moved in arbitrary directions.
- A clickable D-pad that provides movement in four directions.
- Arrow keys plus a center button that’s equivalent to clicking a trackball or d-pad.
All of these types of directional controllers allow users to navigate the screen without using the touch screen. On some devices, a user can also navigate to the top or bottom of a list by holding down the alt key while pressing a discrete key for up or down.
A directional controller is the primary means of navigation for users with visual and some physical impairments and for devices without a touch screen. Verify that all important controls are reachable without using the touch screen and that clicking with the center button has the same effect as clicking on the element on the touch screen.
The ability to navigate to a particular view with a directional controller it is determined via the isFocusable() method. To change whether a view can take focus, call setFocusable(boolean) or set the android:focusable attribute in an XML layout file.
The ordering of the focus movement is based on an algorithm which finds the nearest neighbor in a given direction. In rare cases, the default algorithm may not match the intended behavior of the developer. In these situations, you can provide explicit overrides by using these XML attributes in the layout file:
Clicking with the a directional controller
On most devices, clicking with a directional controller sends a KeyEvent with KEYCODE_DPAD_CENTER. Make sure that this event has the same effect as clicking on the element. All standard Android views already handle KEYCODE_DPAD_CENTER appropriately.
KeyEvent KEYCODE_ENTER as equivalent to KEYCODE_DPAD_CENTER. That makes things easier for devices with a full qwerty keyboard.
Label Your Input Elements
Many input elements rely on visual cues to inform the user of their meaning. For example, an application may use an ImageButton with a picture of a plus sign to indicate that the user can add an entry to a table. Or, an EditText may have a label near it that indicates its purpose. When a visually impaired user accesses your application using Android’s accessibility services, these visual cues are often lost.
The contentDescription attribute that should be used to provide a textual representation of this information. Set this attribute on every ImageButton and EditText and on any other input widget that might benefit from this extra information.
Follow Android UI Best Practices
Developing a user interface that complies with the Android UI guidelines will make it easier for users to learn to use your application. This consistency is especially important for many disabled users, as they may have less contextual information available to try to understand your application’s interface.
Use the view elements provided by the Android SDK whenever possible, as these elements have accessibility support built in.
Send AccessibilityEvents from Custom View Elements
If your application requires that you create a custom view element, you can make your view accessible by implementing the AccessibilityEventSource interface and sending AccessibilityEvents at the proper times.
View classes already implement the AccessibiltyEventSource interface. This interface provides the mechanism for sending events to the registered AccessibilityServices.
There are five types of accessibility events that should be sent as the user interacts with your view.
This should be sent when the user clicks on the view.
This should be sent when the user long clicks on the view.
This should be sent when the selects and item, usually in the context of an AdapterView.
This should be sent when the user focuses on the view.
This should be sent when the text of the view changes.
Each event type requires that particular properties be set, so that the accessibility service can properly respond to the event. Those specifics are detailed in the AccessibilityEvent documentation.
Test Your Application’s Accessibility
You can simulate the experience for many users by enabling an accessibility service that will speak as you move about the screen. One such service is TalkBack, by the Eyes-Free Project. It comes preinstalled on many Android devices, but is also available for free download in the Android Market.
This service requires that you have a text-to-speech engine installed on your phone. You can verify if you have one installed in the Text-to-speech settings menu by selecting Listen to an example. If you do not hear anything spoken, install the required voice data using the Install voice data option.
Once text-to-speech is functioning correctly, you can enable TalkBack in the Accessibility settings menu. Enable both Accessibility and TalkBack. As you navigate about the device, you should now hear spoken feedback.
You can now attempt to use your application as a blind user would. As you move around using only the directional controller, make sure that the spoken feedback hear makes sense and is sufficient to navigate the application without any visual cues.