Level A Robust WCAG 2.0+

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.

Web Content Accessibility Guidelines (WCAG) 2.2

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.

Key Concept: Every interactive element needs three things: a Name (what it's called), a Role (what type of element it is), and a Value/State (its current condition).

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.

Good Example - Native Elements
<!-- 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.

Good Example - Custom Toggle Button
<!-- 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

Good Example - Accordion
<!-- 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 Examples
<!-- 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

  1. Open DevTools Accessibility panel (Chrome: Elements > Accessibility)
  2. Select each interactive element
  3. Verify Name, Role, and Value are present and correct

Screen Reader Testing

  1. Navigate to each interactive element
  2. Verify the screen reader announces: what it is (role), what it's called (name), and its state (value)
  3. 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

Additional Resources