Problem
You must allow certain classes of users, or any user in certain contexts, to consume content without reading the screen.
Practically all mobile devices have audio output of some sort, and it can be accessed by almost every application or website. There can be strict limits, such as devices which only output over headsets, or those which only send phone call audio over Bluetooth, that can limit the use of some tones.
Solution
Mobile devices must be able to read text displayed on the screen for the user, so it can be accessed and understood by those who cannot use the screen.
Due to mobiles being contextually employed, there are numerous instances in which the user may not be able to, not be allowed to, or may choose not to read the screen.
The user may well choose to use Voice Readback to allow themselves to use their hands and eyes for other purposes. While working, or performing hobbies which do not require excessive cognitive load themselves, such as most driving, radio and other audio output is used to gather information or provide entertainment. Video is generally more entertaining, but is totally unsuitable for these situations.
Variations
Voice Readback always works in broadly the same way, but what is being read varies:
Universal - The entire interface is read, to allow the device to be used without any view of the display. This is usually combined with the Voice Input pattern to create a complete voice UI, as an alternative to the conventional button (or touch) and screen UI native to the device. Even if used for only one section, action, or phrase, this same method is used for any readback of voice commands.
Elemental - An entire document, such as a PDF, email or web page is read until the user cancels the action or the entire document is read.
Selected - A selection the user has specified within any context -- for example by highlighting text in a web page -- is read in it's entirety.
Voice output that is presented based on conditions, such as position or time, are discussed under the Voice Notifications pattern.
Interaction Details
Voice Readback can be turned on as a setting for the entire OS, or on an application basis. It will then be used automatically, whenever a change in the application is initiated.
Other input methods, such as keypads and Directional Controls will still function. Buttons will generally be needed to unlock or refresh a screen so that the current condition is read aloud.
Readback can also be initiated, for the Elemental and Selection variations, within the application or as a contextual control such as a Pop-Up, menu, Annotation or other control.
Readback for single-use cases of UI control is the result of Voice Input. Initiation is discussed under that pattern.
Presentation Details
Audio should be played by default through the external speaker, or speakerphone. The last set in-call volume (or equivalent playback volume for non-phones) should be used. Whenever possible, detect the ambient noise level and adjust the volume accordingly, in order to make it audible.
When a headset is attached (either physically or by a link such as Bluetooth), the playback should default to this device, and use the last set in-call volume for this device.
Content read must be identical to that printed on the screen. The condition that resulted in the user employing Voice Readback may be temporary and transient. Allow the user to switch between the screen and audio channels. They may even wish to read along with the voice output. Even for users with a vision deficit, others may be accompanying them, who may also wish to use the device.
Also be sure that content scrolls as the audio gets to that part, so that the item being read back is in the viewport.
There may be delays between phrases, or before the start of the audio readback. To inform the user that audio is about to commence, and to prepare them for the volume level, play a subtle tone immediately beforehand.
Use a similar tone when Voice Readback has stopped for a significant time, or to communicate a selected ovum setting, to confirm this condition to the user.
Antipatterns
Avoid mixing readback of commands and text. When the two must be used together, use delays, tones, changes in voice and clear syntax (such as "You said...") to indicate the difference.
The voice you select must be as understandable as possible. Text-to-voice translation of names, especially, can be difficult to understand or improperly pronounced. If quality is too low with the available hardware and software, do not implement the solution.
Keep in mind that users may be wearing headsets. Some headsets will not accept all output, so if your application relies on Voice Readback, make sure the targeted devices support your application or service sending audio to all attached headsets or other audio devices.
Next: Voice Notifications
Discuss & Add
Please do not change content above this line, as it's a perfect match with the printed book. Everything else you want to add goes down here.
Examples
If you want to add examples (and we occasionally do also) add them here.
Make a new section
Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.