conflicting-state-in-name
Mobile validation
Assistive technologies announce an element's state, such as checked, selected, or on, from its programmatic state, so the accessible name should identify the element and not describe its state. In this case, the accessible name contains state text that contradicts the element's actual state, for example “Agree, checked” on a checkbox that is not checked. Screen readers then announce two opposite states at the same time: one from the name and one from the element's state. Users cannot tell which one is correct, and may make the wrong choice or stop trusting the interface. Remove the state text from the accessible name, and let the element's state be announced on its own.
Note: Even state text that matches the current state should not be part of the name, because it goes out of sync as soon as the state changes. See the related state-in-name validation.
Pass Patterns
Android
The checkbox's contentDescription identifies it without any state text.
<CheckBox
android:id="@+id/agreeCheckBox"
android:layout_width="..."
android:layout_height="..."
android:checked="false"
android:contentDescription="Agree" />The checkbox's contentDescription identifies it without any state text.
Checkbox(
checked = false,
onCheckedChange = {},
modifier = Modifier.semantics {
contentDescription = "Agree"
},
)Cross Platform
child: Semantics(
label: 'Box',
checked: false,
child: Checkbox(
value: false,
onChanged: (_) {},
),
),<Checkbox
accessibilityLabel="Agree"
value={checked}
onValueChange={setChecked}
style={styles.checkbox}
/>Fail Patterns
Android
The contentDescription says “Checked”, but the checkbox is not checked.
<CheckBox
android:id="@+id/agreeCheckBox"
android:layout_width="..."
android:layout_height="..."
android:checked="false"
android:contentDescription="Agree, Checked" />The contentDescription says “Checked”, but the checkbox is not checked.
Checkbox(
checked = false,
onCheckedChange = {},
modifier = Modifier.semantics {
contentDescription = "Agree, Checked"
},
)Cross Platform
child: Semantics(
label: 'Box, Checked',
checked: false,
child: Checkbox(
value: false,
onChanged: (_) {},
),
),The accessibilityLabel says “Checked”, but the checkbox is not checked.
<Checkbox
accessibilityLabel="Agree, Checked"
value={checked}
onValueChange={setChecked}
/>Try It Yourself
Using a screen reader
New to screen reader testing, or need a refresher?
Review this article first: Practical guides for using screen readers
- Turn on VoiceOver on iOS, or TalkBack on Android.
- Swipe right or left to move to the element.
- Listen to the element's name and its state.
Expected results: The screen reader announces the element's name and a single state, for example “Agree, not checked, checkbox”.
Actual results: The screen reader announces two conflicting states, one from the name and one from the element, for example “Agree, checked, not checked, checkbox”.
Tip: To hear the state more easily, set the screen reader to announce it first. On Android, open TalkBack settings > Advanced settings > Element description order and choose "State, name, type". On iOS, open Settings > Accessibility > VoiceOver > Verbosity > Controls and choose "Speak Before".
Using developer tools
- 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 Value.
- Android: In Android Studio, open the Layout Inspector and select the element. Compare its
contentDescription, for Views, or its semantics, for Jetpack Compose, with its checked state.
Expected results: The name contains no state text.
Actual results: The name contains state text, such as “checked” or “on”, that contradicts the element's actual state.
FAQ
How does this issue relate to 4.1.2 Name, role, value?
SC 4.1.2 requires the name and the state of every user interface component to be programmatically determinable. When the name contains state text that contradicts the actual state, assistive technologies receive conflicting information, and users cannot reliably determine the element's state.
Why is this issue marked as Serious?
Screen readers announce both the false state from the name and the actual state from the element. Users may make incorrect choices, such as leaving a setting off because they think it is on, or stop trusting the interface. Because it directly misguides core actions, it is rated serious.
Standards and Regulations
| Standard | Success Criterion | Reference |
|---|---|---|
| WCAG 2.2 | 4.1.2 Name, Role, Value (A) | For all user interface components, the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to assistive technologies. |
| EN 301 549 | 11.4.1.2 Name, Role, Value | Same as the WCAG text. |