Unsupported item type
Screen readers and other accessibility services may announce information about the type of certain interface elements.
- 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.
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||
|Drop down list||
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
- When an app uses an
onInitializeAccessibilityNodeInfo(View host, AccessibilityNodeInfo info)
- Within apps that implement an
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.
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.
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.
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.