Resource guide
4.1.2 Name, Role, Value
All user interface components must have an accessible name, role, and state that assistive technologies can read and report.
By Calling All Minds·Last updated April 2026
Success criterion
Conformance level
Essential baseline — must meet for any compliance.
What it means
This is arguably the most important single criterion in WCAG. It underpins the entire Robust principle. Every interactive element on your page must be understandable to assistive technology: the screen reader must know what something is (its role), what it is called (its name), and what state it is in (its value or state).
Role identifies what a component is: button, link, checkbox, slider, tab. Name identifies what that specific component is called: 'Submit', 'Back to results', 'Subscribe to newsletter'. State identifies its current condition: checked, expanded, selected, disabled.
Native HTML elements get all of this for free. A <button> is identified as a button, its visible text is its name, and its disabled state is communicated through the disabled attribute. Custom components built from <div> and <span> elements have none of this unless you add it explicitly.
In practice
Use semantic HTML wherever possible. <button> for buttons, <a> for links, <input type="checkbox"> for checkboxes. Native elements communicate role, name, and state without any additional work.
For custom components, use ARIA roles to identify the component: role="button", role="tab", role="slider". Use aria-label or aria-labelledby to provide the name. Use ARIA state attributes for state: aria-checked, aria-expanded, aria-selected.
Icon-only buttons must have an accessible name via aria-label: <button aria-label="Close dialog"><svg>...</svg></button>.
Dynamic content changes must be reflected in ARIA state. If a menu expands, aria-expanded must change from false to true.
Common failures
- Custom button built from a
<div>with norole="button", no keyboard support, and no accessible name - Icon button with no
aria-labelor other accessible name - Accordion that expands visually but does not update
aria-expanded - Checkbox built from a
<div>that has no role, name, or checked state communicated to assistive technology - Form input with no associated label and no
aria-label
The tricky parts
ARIA can communicate role, name, and state, but it cannot add keyboard interaction or visual focus. role="button" makes a div identifiable as a button to screen readers, but you must still add keyboard event listeners for Enter and Space and ensure it is focusable via tabindex="0".
The first rule of ARIA is: do not use ARIA if native HTML can do the job. Overusing ARIA on native elements can cause conflicts.
AXS Audit
AXS Audit checks your site against 4.1.2 and flags issues your team can act on straight away. It covers criteria that automated scanners often miss.
