Success Criterion 4.1.2: Name, Role, Value
Official W3C Definition
For all user interface components (including but not limited to: form elements, links and components generated by scripts), 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 user agents, including assistive technologies.
Why This Criterion Matters
Assistive technologies like screen readers need to understand what each interface component is, what it's called, and its current state. Without this information, users cannot effectively navigate or interact with web content.
Understanding the Terms
| Term | Definition | Example |
|---|---|---|
| Name | The accessible name that identifies the component to users | "Submit Order", "Email Address", "Close Menu" |
| Role | What type of UI component it is (button, link, checkbox, etc.) | button, link, checkbox, slider, menu |
| Value | The current value or state of the component | checked/unchecked, expanded/collapsed, 75% |
Who Benefits
Screen Reader Users
Rely entirely on programmatic information to understand and use interface components.
Voice Control Users
Need accessible names to target elements with voice commands like "Click Submit Order".
Keyboard Users
Benefit from properly structured controls that behave as expected.
Automated Tools
Testing tools and browser extensions use this information to evaluate accessibility.
How to Meet This Criterion
Technique 1: Use Native HTML Elements
Native HTML elements have built-in names, roles, and values. Use them whenever possible.
<!-- Button: Role is "button" automatically -->
<button type="submit">Submit Order</button>
<!-- Link: Role is "link" automatically -->
<a href="/products">View Products</a>
<!-- Checkbox: Role, name, and checked state built-in -->
<label>
<input type="checkbox" name="newsletter">
Subscribe to newsletter
</label>
<!-- Select: Role and value built-in -->
<label for="country">Country</label>
<select id="country" name="country">
<option value="us">United States</option>
<option value="ca">Canada</option>
</select>
Technique 2: Add ARIA When Needed
When custom components are necessary, use ARIA to provide name, role, and state information.
<!-- Custom toggle with all required information -->
<div role="button"
tabindex="0"
aria-pressed="false"
aria-label="Dark mode"
onclick="toggleDarkMode()"
onkeydown="handleKeyPress(event)">
<span class="toggle-icon"></span>
</div>
<script>
function toggleDarkMode() {
const btn = document.querySelector('[aria-label="Dark mode"]');
const isPressed = btn.getAttribute('aria-pressed') === 'true';
btn.setAttribute('aria-pressed', !isPressed);
// Update visual state...
}
</script>
Technique 3: Custom Widgets with Complete ARIA
<!-- Accordion header as button -->
<h3>
<button aria-expanded="false"
aria-controls="section1-content"
id="section1-header">
Section 1: Getting Started
</button>
</h3>
<div id="section1-content"
role="region"
aria-labelledby="section1-header"
hidden>
<p>Content goes here...</p>
</div>
<!-- Bad: Div acting as button with no role or name -->
<div onclick="submit()" class="btn">
<i class="icon-check"></i>
</div>
<!-- Bad: Link without href (missing role) -->
<a onclick="navigate()">Products</a>
<!-- Bad: Custom checkbox without state -->
<div class="checkbox" onclick="toggle()">
<span class="checkmark"></span>
Accept terms
</div>
<!-- Bad: Icon button without accessible name -->
<button><i class="fa-trash"></i></button>
<!-- Bad: State change not communicated -->
<div class="dropdown open">...</div>
Providing Accessible Names
There are multiple ways to provide accessible names for UI components:
| Method | Example | Use Case |
|---|---|---|
| Text content | <button>Submit</button> |
When visible text describes the control |
| Label element | <label for="email">Email</label> |
Form inputs |
| aria-label | <button aria-label="Close"></button> |
Icon-only buttons |
| aria-labelledby | <div aria-labelledby="heading1"> |
Reference existing visible text |
| title (last resort) | <abbr title="World Wide Web">WWW</abbr> |
Only for abbreviations; not reliable |
Common Failures to Avoid
| Failure | Problem | Solution |
|---|---|---|
| Custom controls without roles | Screen readers don't know what it is | Add role="button", role="checkbox", etc. |
| Icon-only buttons without names | Screen readers say "button" with no context | Add aria-label or visually hidden text |
| State changes not communicated | Users don't know menu opened or option selected | Update aria-expanded, aria-selected, etc. |
| Links without href | Not recognized as links | Add href or use button with role |
| Form inputs without labels | No accessible name for the field | Associate label element or use aria-label |
| Wrong ARIA role | Confusing behavior expectations | Use correct role matching behavior |
Testing Methods
Browser Developer Tools
- Open DevTools Accessibility panel (Chrome: Elements > Accessibility)
- Select each interactive element
- Verify Name, Role, and Value are present and correct
Screen Reader Testing
- Navigate to each interactive element
- Verify the screen reader announces: what it is (role), what it's called (name), and its state (value)
- Interact with the element and confirm state changes are announced
Automated Testing
- axe DevTools: Flags missing names, roles, and states
- WAVE: Shows accessible names in the structure view
- Lighthouse: Checks for form labels and button names
Key Questions to Ask
- Does every button have an accessible name?
- Does every form input have a label?
- Do custom widgets have appropriate ARIA roles?
- Are state changes (expanded, selected, checked) communicated?
- Can voice control users target elements by name?
Related Criteria
4.1.1 Parsing
Valid markup for proper parsing
1.3.1 Info and Relationships
Semantic structure for content
3.3.2 Labels or Instructions
Labels for form inputs
2.1.1 Keyboard
Keyboard operability