Android Accessibility Properties and TalkBack

Introduction

The Android operating system from Google includes several accessibility features to aid individuals with disabilities in the use of mobile phones and tablets powered by the android platform. Among these is a pre-installed screen reading service called TalkBack which provides nonvisual access to the Android interface for individuals who are blind or visually impaired. TalkBack uses the properties of controls within the user interface of an Android app along with other factors to provide the user with spoken information about a control. In order to understand how accessibility properties set by developers in native Android apps are announced to users of the TalkBack screen reader, SSB tested different properties using the TalkBack 3.51 screen reader on an Android 4.4 device with a keyboard.

In this post we describe the technical measures that are provided within the Android platform by way of available accessibility properties and provide samples of how some of these properties are rendered by TalkBack. Developers, technical policy makers and accessibility/software testers can use this information to understand how TalkBack uses accessibility properties and how to verify and/or test that controls in their applications are implemented in a manner that is as accessible as possible. We are not seeking to point out strengths or weaknesses of the Android accessibility framework , but rather to clarify the technical factors that must be implemented to make native apps accessible. As no inspection or testing tools currently exist to perform accessibility testing of Android native apps, an understanding of the relationship between the accessibility properties available on Android and how these are conveyed to end-users by TalkBack is necessary to developing accessible apps on the Android platform.

Available Properties

The four main accessibility properties for Android controls are hint, contentDescription, focusable and labelFor. While all of these properties can be specified for any control, some properties are designed to only work with specific controls.

The hint property provides an accessible name, or label, for input fields. It is only announced for input fields when the field is not populated. For this reason, SSB does not typically recommend using the hint property as the label for a field since it will no longer be announced when the user fills in the field. The contentDescription property is used to provide an accessible name for controls but is not used with controls which accept text input. The focusable property allows a control to receive keyboard focus and allows for sequential keyboard navigation to a control. The LabelFor property is used to associate an on-screen TextView with a form field. SSB found in testing that the content associated with the labelFor property was always the last item to be announced by TalkBack and that setting other control properties had no impact on the order when the labelFor content was announced.

How Accessibility Information is Determined and Exposed

TalkBack uses the internal structure of a user interface control to determine the various control properties that should be announced such as the control’s role (type). The Android platform implements the Android accessibility Application Programming Interface (API) to communicate other accessibility information to TalkBack and potentially other assistive technologies. A limited set of accessibility API properties and methods are available, including isChecked(), isSelected(), getBoundsInParent(), and isEnabled().

Many controls have a standard text property which provides developers the ability to specify what text appears on screen for the control. In most cases, if the contentDescription property is set by the application developer, the value of the contentDescription will be announced by TalkBack in place of the text associated with the standard text property. This is usually intended to provide a more relevant nonvisual label for a control. If the contentDescription and text property are not set, TalkBack does not announce any label for that particular control.

SSB discovered during testing that all controls would receive both keyboard and swipe focus while TalkBack is running even when the focusable property was set to remove a control from the focus order. While this prevents developers from accidentally removing focus from a necessary control, it also disallows the ability to prevent navigation to a control that other users may not be able to reach. Without TalkBack running, developers should be able to use the focusable property to specify which controls can receive focus. In spite of this, several controls did not appear in the tab order when Talback was not running. Such controls include text views that are not interactive, expandable lists, and date pickers.

Sample Findings

A sampling of the results for controls we tested are reported below.

Text View, Large Text View, Medium Text View, and Small Text View

Setting the hint property on a Text View has no effect. TalkBack reads the on-screen text by default, but if the contentDescription property is set, TalkBack reads this instead of the on-screen text. Without TalkBack running, a TextView is not focusable by default even if the focusable property is set to true.

Button, Small Button, and Toggle Button

Setting the hint property on a button, small button, or toggle button has no effect. TalkBack reads the on-screen text by default, but if the contentDescription property is set, TalkBack will read this in place of the on-screen text. For a toggle button, setting the TextOn/TextOff property also sets the on-screen text for that button. For a button or small button, TalkBack always announces “Button” for the role of the control as the final item. If the control is a toggle button, TalkBack announces a role of “Switch” instead of “Button” to indicate that activating this control will toggle its state. When TalkBack is not running and when the focusable property is set to true, the button, small button, and toggle button controls are focusable by default. If the focusable property is set to false, then these controls are not focusable.

Editable Text

Edit Text fields prompt users to enter information such as name, password or phone number and also include auto-complete fields. TalkBack only announces hints for text input fields when they are empty. The contentDescription is never announced, so setting this property does not have any effect. “Edit Box” is always the first item to be announced. As expected, different on-screen keyboards appeared during testing depending on the type of input field specified.

When TalkBack is not running and when the focusable property is set to true, each of the different types of edit text controls are focusable by default. If the focusable property is set to false, edit controls do not receive focus except for Auto-complete and Multi-line edit controls which appear to remain in the focus order even when the focusable property is set to false.

Additional Accessibility Requirements

Accessibility requirements driven by standards and regulations such as Section 508 or the Web Content Accessibility Guidelines extend beyond those necessary to make apps nonvisually accessible. Other areas that must be addressed include color, animation, multimedia, dynamic content, navigation and input. The Accessibility Management Platform contains a wealth of best practices for Android OS development and validation to address the breadth of requirements for compliance with leading accessibility standards. If you are interested in learning more about AMP, contact an accessibility compliance expert from SSB BART Group.

Co-author: Jonathan Avila, Chief Accessibility Officer