Testing for Accessibility with TalkBack

Accessibility Testing Checklist | Android Developers
  • Set up and use the application without sighted assistance.
  • All task workflows in the application can be easily navigated using directional controls and provide clear and appropriate feedback.
Directional controls: Verify that the application can be operated without the use of a touch screen.
Note: Keyboards and D-pads provide different navigation paths than accessibility gestures. While gestures allow users to focus on nearly any on-screen content, keyboard and D-pad navigation only allow focus on input fields and buttons.
TalkBack audio prompts: UI controls have clear and accurate audio descriptions when TalkBack is enabled and controls are focused. Use directional controls to move focus between application layout elements.
Explore by Touch prompts: UI controls have appropriate audio descriptions when Explore by Touch is enabled. There should be no regions where contents or controls do not provide an audio description.
Touchable control sizes: All controls where a user can select or take an action must be a minimum of 48 dp (approximately 9mm) in length and width, as recommended by Android Design.
Gestures work with TalkBack enabled: Verify that app-specific gestures, such as zooming images, scrolling lists, swiping between pages or navigating carousel controls continue to work when TalkBack is enabled. If these gestures do not function, then an alternative interface for these actions must be provided.
No audio-only feedback: Audio feedback must always have a secondary feedback mechanism to support users who are deaf or hard of hearing, for example: A sound alert for the arrival of a message should also be accompanied by a system Notification, haptic feedback (if available) or another visual alert.
Repetitive audio prompting: Check that closely related controls (such as items with multiple components in a list) do not simply repeat the same audio prompt. For example, in a contacts list that contains a contact picture, written name and title, the prompts should not simply repeat “Bob Smith” for each item.
Audio prompt overloading or underloading: Check that closely related controls provide an appropriate level of audio information that enables users to understand and act on a screen element. Too little or too much prompting can make it difficult to understand and use a control.

Basic TalkBack Testing Methods

  1. Enable TalkBack
  2. Check the Name, Role, Value, State of each element.
  3. Set focus to all UI elements in the app and make sure the accessible name (contentDescription) makes sense. Make sure text alternatives for images match fully.
  4. If UI element is actionable should it have a role like button or tab? Static text would not have a role. (Called traits on iOS, role in WAI-ARIA)
  5. Adjustable controls like sliders must have their current Value spoken to TalkBack.
  6. Is the current state of a control spoken? E.g. is this tab the selected tab? Is this element expanded or collapsed?
  7. Images that are purely for decoration (have no function) should not be focusable.
  8. Is there proper focus management when new content appears on the screen? E.g. when a dialog appears does the TalkBack focus go into the dialog? Is it trapped in the dialog? Or is the focus still stuck underneath the dialog? Is focus lost when the dialog is closed? Does focus return to the UI element that opened the dialog? When error messages appear are the spoken automatically by TalkBack?
  9. Is the focus order logical when swiping through elements or using directional controllers? Generallly follow the visual reading order, left to right, top to bottom.
  10. Is the TalkBack user aware of gestures specific to your app that they need to know to activate content or features? If those custom gestures conflict with TalkBack is there an alternative method to acheive the same function?