Compliance Audit
PUBLIC / REFERENCEEngine
WCAG 2.2 / RULE REFERENCE

WCAG 4.1.2 — Name, role, value

4.1.2 keeps custom components honest: assistive technology cannot operate what it cannot name. Every control needs an accessible name, a programmatic role, and states that update live. It is Level A, and it is where bespoke date-pickers, toggles, and mega-menus break — the DOM looks right while the accessibility tree is empty.

The rule

UI components must expose their name, role, state and value to assistive technology. Level A — the criterion custom widgets most often break.

What it means for how you build

Prefer semantic HTML; when you must go custom, ARIA roles and states are part of the component contract, not an afterthought.

Self-check

  • Does every interactive element expose a name, role, and current state to the accessibility tree?
  • Do ARIA states — aria-expanded, aria-checked, aria-selected — actually change on interaction?
  • Are icon-only buttons labelled — aria-label or visually-hidden text?
  • Does validation status reach AT — aria-invalid, live-region announcements?

Common pitfalls

  • ARIA present but never wired: aria-expanded="false" on a menu that is visibly open.
  • Div-buttons: if it needs a click handler it is a component — without role and key handling it fails.
  • Icon glyphs as names: a font-icon character is not an accessible name.

How the engine checks it

axe ruleset detection in the audit run — missing accessible names and misused roles surface as findings.

Last reviewed 2026-11-01.

Reading up on WCAG 4.1.2 — Name, role, value? The engine verifies this surface from the perimeter — live on sovereign EU/UK partitions.