Interactive elements must have a defined role that assistive technologies can programmatically read and announce.

Who might be affected
Screen Reader
Voice Control


The role of an element is like a promise. It allows users (mainly screen reader users) to infer and predict the element's behavior and the outcome of interacting with it. For example, if an element is being read as a link, the user can infer that interacting with it will lead to another screen or an external page. If it is being read as a checkbox or a switch, the user can infer that the interaction will toggle between checked and unchecked or on and off, respectively.
In most cases, interface components of the various frameworks have roles by default. When expanding an existing role, ensure that the behaviors added match those expected from the role.
In cases where a custom interactive element is defined, you must specify its role with the proper attributes.

Quick Fixes

Ensure that all interactive elements have a properly defined role that reflects their functionality.


Java (Pass technique)

1View view = (View) findViewById(;
2view.setAccessibilityDelegate(new View.AccessibilityDelegate() {
3 @Override
4 public void onInitializeAccessibilityNodeInfo(View host, AccessibilityNodeInfo info) {
5 super.onInitializeAccessibilityNodeInfo(host, info);
6 AccessibilityNodeInfoCompat.wrap(info).setRoleDescription("carousel");
7 }

Kotlin (Pass technique)

1val view = findViewById<View>(
2view.accessibilityDelegate = object : View.AccessibilityDelegate() {
3 override fun onInitializeAccessibilityNodeInfo(host: View, info: AccessibilityNodeInfo) {
4 super.onInitializeAccessibilityNodeInfo(host, info)
5 AccessibilityNodeInfoCompat.wrap(info).roleDescription = "Button"
6 }

Compose (Pass technique)

1fun CustomButton() {
2 Box(
3 modifier = Modifier.semantics {
4 onClick { }
5 role = Role.Button
6 contentDescription = "Approve request"
7 }
8 )

How Users Are Affected

A sighted user can deduce the type of an element and, as a result, how to use it and the expected outcome from using it based on its appearance. The average user knows common visual patterns associated with specific behavior or functionality. For blind users, this visual context is lacking. A proper role definition allows a screen reader to read the element's role to somewhat bridge this gap. The effect of the absence of a role will usually be more significant on iOS users because VoiceOver gives no further indication of the element's role besides announcing its type, while Android screen readers like TalkBack will indicate that the element is operable if there is an event listener attached to it by hinting the expected action (like a double-tap to activate).

WCAG Success criteria

This issue might cause elements to fail one or more of the following Success criteria:
1.3.1 info and relationships (A) | 4.1.2 name, role, value (A)