TalkBack is an assistive technology for the Android Operating System which allows users to read and interact with textual expressions of the interface by using various swipe gestures and by tapping on the screen. TalkBack, and the highly related BrailleBack, work with the Operating System to share information about controls with users through simple audible announcements. Accessibility testing with TalkBack is very complicated, as you will see when you look at the "Setting Up TalkBack for Testing" section.

Those accustomed to the more structured environments of iOS or the Web should know that Android has much less structure to its announcements. Where iOS and ARIA try and separate things into Name, Role, and Value... Android thinks of it more like Description and Actions. While also leaving in a bit of legacy behavior in terms of essentially announcing the ClassName of the control as a pseudo Role... always trips people up.

This article assumes you have used TalkBack before. A more intro article will be available in the future.

Setting Up TalkBack for Testing

If you are a TalkBack user, you probably have your own TalkBack configuration that you prefer and you may be able to hear the nuanced difference between a comma (,) and a {pause}. For those of us who don't use TalkBack regularly, the following settings can help extract the most information for testing purposes.

1. Verbosity Settings
   1. Where: TalkBack > Settings > Verbosity
   2. Why: Any other configuration for these settings hides information important for testing purposes.
   3. Important Verbosity Settings
      1. Speak Usage Hints: On
      2. Speak List/Grid Info: On
      3. Always Speak Number of List Items: On
      4. Speak Element Type: On
      5. Speak Window Names: On
      6. Capital Letters: Not set to "Do Nothing"
      7. Speak All Progress Updates: On
      8. Speak Element IDs: Off
         1. Note: Adds information the developer didn't intend the user to hear.
      9. Speak Punctuation and Symbols: On
2. Sound and Vibration
   1. Where: TalkBack > Settings > Sound and Vibration
   2. Why: Any other configuration for these settings hides information important for testing purposes.
   3. Important Sound and Vibration Settings
      1. Sound Feedback: On
      2. Audio Ducking: On
      3. Vibration Feedback: On
3. Automatic Descriptions
   1. Where: TalkBack > Settings > Automatic Descriptions
   2. Why: When these options are on they add information that the developer did not intend, therefore creating a misleading test.
   3. Important Automatic Descriptions Settings
      1. Describe Icons: Off
      2. Describe Images: Off
      3. Describe Text in Images: On for Unlabelled Images only
         1. Note: OCR is reliable and a generally available feature. When the correct text is detected I generally give this a pass.
4. Element Description Order
   1. Where: TalkBack > Settings > Advanced > Element Description Order
   2. Why: When developers "hack" a Role onto a ContentDescription they almost always do it in the default order. By having this set to anything BUT the default order you can easily catch said developers being lazy. 😄
   3. Set To: Anything but "State, Name, Type"
5. Speak Passwords
   1. Where: TalkBack > Settings > Advanced > Speak Passwords
   2. Why: It is important for TalkBack user's privacy that password fields are built properly. Otherwise TalkBack could announce a users private information out loud for those around to hear. Having this setting set to off let's you hear when this is broken! 😄
   3. Set To: Off
6. Typing Preference
   1. Where: TalkBack > Settings > Advanced > Typing Preference
   2. Why: Not required... but a real time saver!
   3. Set To: Hold finger to select letter key, then lift. Double-tap for other keys.
7. Display Speech Output
   1. Where: TalkBack > Settings > Advanced > Developer Settings
   2. Why: To help you differentiate between different pieces of information... State, Role, Description, Etc.
   3. Set To: On
8. Grab a Coffee... Phew.

The Testing Process

Now that TalkBack is optimized for testing, let's take a look at some key elements of the testing process:

1. Pre-req: Turn on TalkBack
2. For Each: Screen Change
   1. Announcements and focus transitions that occur are reasonable.
3. For Each: Unique Screen
   1. Touch to Explore gestures can focus all Views.
   2. Contextual Navigation
      1. Headings: Should skip to top level navigational landmarks.
      2. Controls: Should skip to top level interactive landmarks.
   3. Focus Order and Information Structure is reasonable.
   4. Listen for background audio and ensure audio ducking is working properly.
4. For Each: Unique Component
   1. Accessibility announcement is concise and reasonable.
   2. Default action activates on Double Tap.
   3. Custom Actions list is reasonable.

Below are a few comments on things to look out for.

Activity and Fragment Transitions

Whenever a new view is loaded – whether that is a new screen, a modal dialog, or a picker – pay attention where TalkBack focus is sent and any announcements that occur during this transition. In the majority of cases the Operating System should recognize a new view has been loaded and introspect the view to find where it should send focus (i.e. the title of the screen, the first form field on the screen, etc).

The goal here isn't to micromanage focus, but to ensure it moves to a reasonable place. If it doesn't, there might be an issue with the way the new view has been loaded such that the Operating System doesn't recognize it. In some edge cases, manually managing focus may be justified.

Explore Informative Elements by Touch

For testers coming from the Web Ecosystem it may be tempting to do the linear navigation test and be done! But, don't forget that Touch To Explore is a way to gain information from TalkBack as well. In fact, there's actually quite a bit of information in locality and grouping, and unlike the mouse on a computer... your input device (your thumb) is attached to you! So, you actually get quite a bit of information from dragging your finger around the screen... even if you're blind.

Look for opportunities to expand the touchable area of controls to make them more discoverable! Particularly valuable are times when elements cover most of the width of the screen.

Don't Forget Contextual Navigation

Swiping Right/Left always do the same thing... Accessibility Focus Foward/Backward. However, swiping up and down does different things based on the Contextual Navigation setting. You can change this setting in different ways based on your TalkBack version.

On my Pixel 8 I Swipe Up/Down with 3 fingers to change this setting and can select between:

1. Characters
2. Words
3. Paragraphs
4. Lines
5. Controls
6. Links
7. Headings
8. Actions

For words, characters, and paragraphs there isn't much to test. It's difficult to break these configurations. Though, if you're arguing with a WCAG expert it could be useful to point out that Characters mode is available, so you can quickly end debates about whether or not "All Capital Letters" is confusing or not... it's the Text to Speech engine's fault! 😄

However, for Controls, Headings, Links, and Actions there is quite a bit to test and you should do so carefully. Those navigation modes are quite valuable.

Audio Ducking

Audio ducking should have the effect of bringing audio in/out of focus so that the user can always hear TalkBack announcements prominently, without having to pause advertisements or ambient application sounds. Accessibility experts will often balk about requiring "pause/hide" controls for audio/video content. This is actually Android's solution to this. So, as long as your application uses the correct audio channel/embeds videos properly there's an entire WCAG Success Criteria you can forget about... thanks Google!

Conclusion

The testing process outlined above aims to simplify the nuances of TalkBack testing and can serve as a guide for experienced accessibility testers. There's a lot more we could dive into, and will, in future articles.