WCAG 4.1.2 Name, Role, Value — Testing Guide

WCAG 4.1.2 Name, Role, Value (Level A) requires that for every UI component, the assistive technology must be able to determine: what it is called (name), what kind of thing it is (role), and its curr

WCAG 4.1.2 Name, Role, Value (Level A) requires that for every UI component, the assistive technology must be able to determine: what it is called (name), what kind of thing it is (role), and its current state (value/state). Miss any of these and assistive tech users cannot operate the component.

What it requires

• Name — accessible label announced by screen reader ("Submit button", not "button")
• Role — type of component (button, link, checkbox, tab, heading, etc.)
• Value/State — for interactive components, the current value or state (checked/unchecked, expanded/collapsed, "3 of 5")

For standard HTML / native widgets, these come free. For custom widgets, you must set them explicitly.

Common violations

1. Custom dropdown with no role

<!-- Bad -->
<div class="dropdown" onclick="toggle()">Select</div>

Screen reader says "Select" — does not know it is a dropdown, cannot expand with keyboard, cannot list options.

Fix: use or add full ARIA combobox pattern.

2. Button without accessible name

<button>✕</button>

Screen reader says "button" — no name. User does not know what this button does.

Fix:

<button aria-label="Close">✕</button>

3. Toggle with no state announcement

<div class="toggle" onclick="toggle()">Dark Mode</div>

Visually on/off, screen reader cannot tell.

Fix:

<button role="switch" aria-checked="true" aria-label="Dark mode">Dark Mode</button>

4. Custom checkbox not announced

Div styled as checkbox, click handler toggles a class.

Fix: role="checkbox" aria-checked="true" plus keyboard support (Space toggles).

5. Progress bar with no value

<div class="progress-bar" style="width: 40%"></div>

Screen reader does not know it is a progress bar or its value.

Fix:

<div role="progressbar" aria-valuenow="40" aria-valuemin="0" aria-valuemax="100"
     aria-valuetext="40 percent loaded"></div>

Native mobile

Android

• contentDescription for name
• setAccessibilityLiveRegion for dynamic updates
• Custom views: AccessibilityDelegateCompat to set roles and states
• Compose: Modifier.semantics { role = Role.Checkbox; contentDescription = "..."; toggleableState = state }

iOS

• accessibilityLabel for name
• accessibilityTraits for role
• accessibilityValue for value/state
• SwiftUI: .accessibilityLabel("Close"); .accessibilityAddTraits(.isButton); .accessibilityValue("checked")

Testing

Automated

• axe-core (web)
• Accessibility Scanner (Android)
• Accessibility Inspector (iOS)

These catch:

• Missing labels
• Missing roles on generic elements
• Empty buttons / links

They miss:

• Semantically wrong roles (using role="button" on a link)
• Labels that are technically present but unhelpful ("button 3")

Manual

Tour with screen reader. At every element ask: did I hear its name? Role? State?

Code review

Every new custom component needs an accessibility review. Every

with onclick is suspect.

How SUSA catches 4.1.2

SUSA's accessibility_user persona explores the app with VoiceOver/TalkBack semantics. It flags:

• Interactive elements without contentDescription / accessibilityLabel (critical)
• Custom views without roles (high)
• Toggles without state announcement (high)
• Buttons with icon-only labels where the icon has no description (medium)

For web, axe-core runs on every screen. Results are scored per criterion.

susatest-agent test myapp.apk --persona accessibility_user

The "custom component" trap

Any time you build a component from scratch instead of using the platform's, you take on responsibility for name, role, value, keyboard, focus, and state announcement. Teams underestimate how much comes free with native widgets. A custom dropdown is not "just a dropdown" — it is weeks of accessibility work to get right.

If you must build custom, follow the WAI-ARIA Authoring Practices patterns exactly. They are prescriptive but battle-tested.

Fix order

1. Scan with automated tools, fix the mechanical issues
2. Manual screen reader tour of every screen
3. Build an accessibility-focused test suite that asserts label, role, state
4. Make it a merge requirement for any PR touching UI

4.1.2 is fundamental. Violations mean screen reader users simply cannot use the component. The fix is almost always small code changes. The cost of shipping without is exclusion of a user population and legal exposure in regulated markets.

Test Your App Autonomously

Upload your APK or URL. SUSA explores like 10 real users — finds bugs, accessibility violations, and security issues. No scripts.

Try SUSA Free

Related Articles