Name, Role, Value

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

<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>

<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

• W3C: Understanding Success Criterion 4.1.2 (Name, Role, Value)

See also

• 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.