conflicting-type-in-label

An element's accessible name should describe its purpose, not its control type. Assistive technologies already announce the element's role, such as “button” or “checkbox”, from its programmatic role. In this case, the accessible name contains a type that contradicts that role, for example “Submit, link” on a button. Screen readers then announce two different types for the same element, and users may misinterpret what it is and how to operate it. Voice control users may also have to include the wrong type in their commands. Remove the type from the accessible name, and let the element's role be announced on its own.

Pass Patterns

Android

<Button
    android:id="@+id/submitButton"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Submit" />

iOS

let submitButton = UIButton(type: .system)
submitButton.setTitle("Submit", for: .normal)

Button("Submit") {
    submit()
}

Cross Platform

Semantics(
  label: 'Agree',
  checked: false,
  child: Checkbox(
    value: false,
    onChanged: (_) {},
  ),
),

<Pressable
  accessibilityRole="button"
  accessibilityLabel="Submit"
  onPress={submit}
>
  <Text>Submit</Text>
</Pressable>

Fail Patterns

Android

<Button
    android:id="@+id/submitButton"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:text="Submit"
    android:contentDescription="Submit, Checkbox" />

iOS

let submitButton = UIButton(type: .system)
submitButton.setTitle("Submit", for: .normal)
submitButton.accessibilityLabel = "Submit, image"

Button("Submit") {
    submit()
}
.accessibilityLabel("Submit, image")

Cross Platform

Semantics(
  label: 'Agree, Button',
  checked: false,
  child: Checkbox(
    value: false,
    onChanged: (_) {},
  ),
),

<Pressable
  accessibilityRole="button"
  accessibilityLabel="Submit, image"
  onPress={submit}
>
  <Text>Submit</Text>
</Pressable>

Try It Yourself

Using a screen reader

1. Turn on VoiceOver on iOS, or TalkBack on Android.
2. Swipe right or left to move to the element.
3. Listen to the element's name and its role.

Expected results: The screen reader announces the element's name and a single role, for example “Submit, button”.

Actual results: The screen reader announces two different types, one from the name and one from the element's role, for example “Submit, link, button”.

Using developer tools

1. iOS: In Xcode, open Xcode > Open Developer Tool > Accessibility Inspector, select the simulator or device, and point at the element. Compare its Label with its Traits.
2. Android: In Android Studio, open the Layout Inspector and select the element. Compare its contentDescription, for Views, or its semantics, for Jetpack Compose, with the element's type.

Expected results: The name contains no type, such as “button”, “link”, or “checkbox”.

Actual results: The name contains a type that contradicts the element's actual role.

FAQ

Standards and Regulations

Personas impacted by this issue

• Voice Input
• Screen Reader

Related Issues

• conflicting-state-in-name
• conflicting-traits
• instruction-in-name
• interactable-role
• state-in-name
• type-in-label