Screen readers and other accessibility services may announce information about the type of certain interface elements. For example:
- A screen reader may speak "checkbox" after the label associated with a
CheckBox, informing the user that the element is a checkbox that can be selected or deselected. - A braille display may place square brackets around the label associated with a
Button, to inform the user that the element is a button that is interactive.
Implementation
Elements within an app’s interface provide information to accessibility services by populating an AccessibilityNodeInfo. To convey an element’s type, set its className with a value corresponding to the most similar canonical class name, choosing from types available in the Android SDK or support libraries.
The following table lists some common examples. Note that this table isn't a complete set, and different services support describing different types of widgets.
| Sample UI element type | AccessibilityNodeInfo class name |
|---|---|
| Button | android.widget.Button |
| Toggle button | android.widget.ToggleButton |
| Radio button | android.widget.RadioButton |
| Checkbox | android.widget.CompoundButton |
| Edit box | android.widget.EditText |
| Image | android.widget.ImageView |
| Progress bar | android.widget.ProgressBar |
| Drop down list | android.widget.Spinner |
In most cases, the class name is set by the base implementation of a View, and no additional work is required. However, apps occasionally use custom views that provide their own AccessibilityNodeInfo representation, such as:
- When an app uses a class that extends View, and implements
onInitializeAccessibilityNodeInfo(AccessibilityNodeInfo info) - When an app uses an
AccessibilityDelegatethat implementsonInitializeAccessibilityNodeInfo(View host, AccessibilityNodeInfo info) - Within apps that implement an
ExploreByTouchHelper
In cases where apps provide their own AccessibilityNodeInfo representation, it’s important to provide a class name that most closely describes the type of the UI element. The class name should match a class that extends android.view.View and is provided within the Android SDK or support libraries.
Important: Android’s accessibility services cannot load classes from your application’s package, so avoid setting class names that are provided by your own app.
Avoid using android:contentDescription or other fields within AccessibilityNodeInfo to describe a UI element’s type. While this approach may seem to work for one type accessibility service, it could cause issues with others. Learn more about items labeled with type or state.
Design
When designing novel or custom UI elements, consider how the element should represent itself to people using an accessibility service. Determine which type of Android-provided UI element best describes your design.
Testing
Android accessibility services use different strategies to describe a UI element's type to users. In many cases, the service may choose to not provide any additional description of an item's type, which is expected.
To manually identify problems related to unknown item types, you can test your app with Android’s accessibility services. Look for cases where the UI might be less usable or understandable due to an omitted item type. To fix these issues, you can provide a suitable class name within the element’s AccessibilityNodeInfo representation, or change the element’s label to be more descriptive.
Android's automated testing tools can detect some unsupported item types. Consider using Accessibility Scanner for Android for manual testing of your app on-device. For automated tests, turn on accessibility checking in Espresso and Robolectric.