Success Criteria

WCAG 4.1.2 Name, Role, Value

Success Criterion 4.1.2 requires that for every user interface component, its name and role can be programmatically determined, its states/properties/values can be set by the user (where applicable), and any change in those is communicated to assistive technology. It's a Level A criterion under Guideline 4.1 (Compatible) — and by rule count, the single most heavily-represented criterion in axe-core's entire ruleset (dozens of individual rules trace back to this one requirement).

Why it's phrased as three separate things

Name — what the control is called (a button's accessible name, a link's purpose, a form field's label).

Role — what kind of control it is (button, link, checkbox, tab) — communicated automatically by real HTML elements, but something a custom <div>-based widget has to declare explicitly via ARIA role.

Value (and state) — for controls that hold a value or state (checked/unchecked, expanded/collapsed, selected), that state has to be exposed and kept in sync as it changes.

A component that's missing any one of these three is incompletely described to assistive technology, even if the other two are fine.

Where this criterion actually shows up

Because "name, role, value" is such a foundational requirement, a huge number of more specific, easier-to-name violations are really 4.1.2 failures underneath:

• An icon-only button with no accessible name — see Empty Links and Buttons
• ARIA attributes that are misspelled, invalid, or missing required companions — see Invalid ARIA Attributes
• An iframe with no title, leaving embedded content unnamed — see Missing Iframe Titles
• A form field with no programmatic label — see Missing Form Labels
• A custom toggle/checkbox built from a <div> that never updates aria-checked when its state changes

The unifying fix: prefer native HTML

Nearly every 4.1.2 violation traces back to the same root cause — recreating a native HTML control's behavior on a generic element instead of using the real thing. A real <button>, <input type="checkbox">, or <select> satisfies name/role/value automatically, for free, with zero ARIA needed. This is the practical meaning of "don't use ARIA if native HTML already does the job" — 4.1.2 is the criterion that rule exists to protect.

Common questions

What is WCAG 4.1.2?

A Level A criterion requiring every interactive component to programmatically expose its name (label), role (what kind of control it is), and current state or value.

What commonly fails 4.1.2?

Custom widgets built from generic div/span with no role or ARIA, so a screen reader announces them as meaningless text instead of a button, checkbox, etc.

How do I comply?

Prefer native HTML elements (button, input), or apply correct ARIA roles, names, and states when building custom components.