What this criterion requires
Every user interface component must expose its name, role, states and values to assistive technology, and notify it when they change. Native HTML elements do this automatically; custom components must do it via ARIA.
Who it helps
Screen reader and voice control users - without name and role, a control is announced as "clickable" or nothing at all.
Example: fails vs passes
<div class="dropdown" onclick="toggle()">Menu</div><button aria-expanded="false" aria-controls="nav-list" onclick="toggle(this)">Menu</button>Name ("Menu"), role (button) and state (aria-expanded) - and update the state in JS when it changes.
How to meet and fix it
- Prefer native elements: button, a, input, select give name/role/value for free
- For custom widgets follow the ARIA Authoring Practices: correct role, accessible name, and state attributes (aria-expanded, aria-checked, aria-selected)
- Keep states updated in JS when the UI changes
Common failures auditors find
- A div styled as a button with no role or name
- Custom checkboxes with no aria-checked
- Accordions whose aria-expanded never updates
Automated scanning catches a share of these instantly - run a free check - and a manual audit covers the judgement calls a tool cannot make.
In PDF documents
Interactive PDF form fields must expose name, role and value through the form dictionary and tags - buttons, checkboxes and radio groups included.
Check any document against this and 80+ more automated checks with the free PDF accessibility checker.
- W3C, Understanding 4.1.2: Name, Role, Value - w3.org/WAI
- W3C, How to Meet 4.1.2 (quick reference) - w3.org/WAI/quickref
Last updated . Reviewed by the EqualWeb accessibility team.
Does your site pass 4.1.2?
Run a free automated check now, or have certified IAAP/CPWA auditors test every criterion and document the result.