Interactable elements must be included in the accessible tree.

Who might be affected
Screen Reader
Voice Control


In many cases, custom UI elements are not registered to the accessibility tree by default, and therefore are ignored by assistive technologies such as screen readers and voice control software. Hence, elements that should receive user inputs (e.g., tap events, text input, etc.) must be included in the accessibility tree to be available for assistive technologies users.

Note: In most cases the accessibility of controls such as buttons, links, etc is enabeled by default. However usually when building custom views you will need to enable the accessibility features yourself.

Quick Fixes

iOS (SwiftUI):

SwiftUI allows to explicitly define if an element is exposed on the accessibility tree, like the example below:

1MyCustomView {
2 // The view's content
3 }
4 .accessibilityHidden(false)

However, views can be implicitly added to the accessibility tree by adding them accessibility attributes such as accessibilityLabel for example.

2 ** As you can see, in this case the `accessibilityHidden` is not defined.
3 ** However the view is registered to the accessibility tree due to its
4 ** `accessibilityLabel` attribute.
7MyCustomView {
8 // The view's content
9 }
10 .accessibilityLabel("Show more options")

Android (Kotlin):

1<!-- TBD -->

Android (Java):

1<!-- TBD -->

React Native:

1<View accessible={true}>
2 <Text>Welcome to our store</Text>
3 </View>

Important Note: In some cases enabling a view’s accessibility is a prerequisite for enabling other accessibility characteristics such as labels, hints, identifiers, and traits.

How Users Are Affected

Users of assistive technologies that depend on the accessibility tree to determine the element type and content will not be able to perceive the element nor use it.

WCAG Success criteria

This issue might cause elements to fail one or more of the following Success criteria:
1.3.3 Sensory Characteristics (A) | 4.1.2 name, role, value (A)