← All criteria

Robust · Level A · 4.1.2

Name, Role, Value

Every UI component needs a name, a role, and — where applicable — a state or value that assistive technology can read and, where the user can change it, update.

  • Blind
  • Low vision
  • Motor
The problem, in practice — select the image to enlarge it
A set of UI components compared with ones exposing no name, role, or value versus ones exposing all three. 'Without name, role, or value' shows an unlabeled hamburger icon, an unlabeled checkbox, an unlabeled slider, a Submit button with no accessible name, and a toggle switch with no state, each leaving assistive technology unable to say what it is or how it's set. 'With name, role, and value' shows the same five components each paired with a Name/Role/Value breakdown and the resulting screen reader announcement, such as 'Main menu, button, collapsed' or 'Dark mode, switch, on'. A table beneath maps seven common component types — button, checkbox, text input, slider, dropdown, tab, and progress bar — to their expected name, role, and value plus the exact announcement a screen reader would produce.

How to recognize it

Web design keeps getting more visually polished and more feature-rich, and that makes it easy to drift away from the plain, recognizable HTML elements the browser already understands and knows how to adapt for the user. Instead of a native element, teams reach for a generic <div> or <span> to get an exact visual result — and that generic element hides the very functionality browsers would otherwise expose automatically. To check for it: turn off the mouse and tab through the page, or turn on a screen reader. A <div> styled to look like a button that does nothing when you tab to it and press Enter is failing. A custom checkbox or toggle that a screen reader reads only as 'clickable' with no indication of on/off is failing. A custom dropdown that never announces whether it's open or closed is failing. Note the difference from 2.4.4 (Link Purpose): there, a name exists but is ambiguous; here, there's often no name — or no role, or no state — at all.

How to fix it

Use the native HTML element for the job — <button>, <input type="checkbox">, <select> — whenever you can; it gets the correct role, an accessible name from its label, keyboard support, and state handling for free, with zero extra code. When a custom widget is genuinely unavoidable (a design system component, a widget with no native equivalent), you have to build all of that back by hand: an ARIA role (role="checkbox", role="combobox"...), an accessible name (visible text, aria-label, or aria-labelledby), keyboard support (tabindex plus your own Enter/Space handlers), and state attributes you update with JavaScript every time the state changes (aria-checked, aria-expanded, aria-pressed).

Example

Avoid

<div class="btn" onclick="submitForm()">Submit</div>
<span class="checkbox" onclick="toggle(this)"></span> Email me updates
<div class="icon-btn" onclick="closeModal()"><svg>...</svg></div>

Prefer

<button onclick="submitForm()">Submit</button>
<input type="checkbox" onchange="toggle(this)" id="updates"> <label for="updates">Email me updates</label>
<button aria-label="Close dialog" onclick="closeModal()"><svg>...</svg></button>

Resources

  • 2.4.4 Link Purpose (In Context)

    Shares the same underlying concern — assistive technology needs to know what a control is and does — but comes at it from the other side: 4.1.2 only requires that a name exists at all, while 2.4.4 requires that the name also be meaningful.

  • 1.3.1 Info and Relationships

    A form label tied to its input with <label for> is both: it's the relationship 1.3.1 cares about, and it's also how the input gets the accessible name 4.1.2 requires. Same markup, two criteria satisfied at once.

  • 1.1.1 Non-text Content

    For an icon-only button or control, the icon itself is decorative (alt="") — that's 1.1.1's call — while the button having an accessible name at all is this criterion's job.

  • 2.1.1 Keyboard

    Both push toward the same fix — native elements, or custom widgets rebuilt by hand. This criterion is about the widget being named and announced; 2.1.1 is about it being reachable and operable without a mouse at all. A widget can pass one and fail the other.

  • 2.4.3 Focus Order

    Moving focus into a dialog is 2.4.3's concern; the dialog having role="dialog" and an accessible name is this criterion's concern. A dialog needs both — focus with no role tells a screen reader user where they landed but not what they're in.

  • 2.5.3 Label in Name

    This criterion just requires that an accessible name exists at all; 2.5.3 goes further and requires that the name actually contain the visible label text, not just any name.