WCAG 4.1.2 Name, Role, Value

What it asks

A screen reader does not see a button. It reads the accessibility tree, a version of the page the browser builds for assistive software, and announces what it finds there: "Search, button" or "Remember me, checkbox, checked". For that to work, every control needs a name, a role and, where it has one, a value or state. Standard HTML elements give all three for free. A <button> is a button, its text is its name, and the browser tracks its state.

The problems start with custom controls. A <div> with a click handler has no role, so a screen reader announces nothing or reads it as plain text. An icon button with no text has a role but no name, so it is announced as "button" and nothing more. A home-made accordion that never updates aria-expanded has a name and a role but lies about its state. All three are failures of this criterion, and it is the highest-volume criterion in most audits after colour contrast.

The last part of the rule is about change. When a toggle is switched or a tab selected, the new state has to reach assistive software, which means the attributes must be updated when the state changes, not only set on load. The criterion is Level A. The former 4.1.1 Parsing, which sat beside it in WCAG 2.0 and 2.1, was removed in WCAG 2.2, because modern browsers repair the markup errors it covered; the broken ARIA it used to catch is now a question for 4.1.2.

Its official name is success criterion 4.1.2 Name, Role, Value, at Level A. It was added in WCAG 2.2, under guideline 4.1 Compatible and the principle Robust. The W3C’s normative text says, in part:

“For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.”

From WCAG 2.2, W3C. Full explanation: Understanding 4.1.2 Name, Role, Value.

Who it helps

Screen reader users, who depend entirely on the name, role and state to know what a control is and what it will do. People who use voice control, who say the name of a control to activate it, and cannot activate a control that has none.

People using switch access and other assistive software that lists the controls on a page, and anyone whose browser or extension adapts a page based on what its controls are.

What passes and what fails

These pass

• A <button> with visible text, or an icon button with aria-label="Search".
• A custom accordion whose header is a <button> with aria-expanded that switches between true and false as it opens and closes.
• A native <select> with a <label>, which gives name, role, value and change notification without any ARIA.
• A tab set with role="tablist", role="tab" on each tab and aria-selected kept up to date.

These fail

• An icon button with no text and no aria-label, announced as "button".
• role="button" on a <div> with no name and no keyboard handling.
• An accordion whose aria-expanded is set to false on load and never updated.
• A custom select built from <div> elements with no role at all.
• aria-hidden="true" on an element that can still receive focus, so the keyboard lands on something the screen reader cannot see.

How to test it by hand

1. Open the browser’s developer tools and the accessibility panel, and work through every control: links, buttons, fields, custom widgets.
2. For each, check that it has a name that says what it does, and a role that says what kind of control it is. An empty name or a generic role on an interactive element is a failure.
3. Operate every control that has a state: open accordions, switch toggles, select tabs, pick options in custom selects. Watch the accessibility panel to see whether the state updates.
4. Check for aria-hidden on anything focusable and for interactive elements nested inside other interactive elements, such as a button inside a link.
5. Repeat with a screen reader and listen to what is announced for each control, before and after operating it.

What automated testing can decide

What a machine can decide

Much of this is mechanical. Automated testing can find every interactive element with no name, every element whose ARIA role or attributes are invalid, every focusable element hidden from assistive software, and every interactive element wrongly nested inside another. Those are real failures, not matters of opinion. It can also operate a custom control and see whether its state attributes change.

What it cannot

A perfect snapshot can still hide a broken widget: a control whose aria-expanded is set correctly on load and never updated looks fine until someone opens it. That needs interaction, and a tool only tests the controls it reaches and the states it tries. Whether a name is a good name, rather than merely present, is a judgement, and so is whether a custom widget’s role is the right one for what it does.

How Dreven handles it

Dreven finds the interactive elements and custom controls on your pages, such as accordions, toggles, tabs and comboboxes, and shows you what assistive software is told about each one’s name, role and state, with the page and a picture of it.

A reviewer decides each result, and the report says how each one was decided.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 1.3.1 Info and Relationships (Level A). Structure such as headings and lists must be in the code too; 4.1.2 covers the controls.
• 2.1.1 Keyboard (Level A). A control with a role also needs to work from the keyboard.
• 4.1.3 Status Messages (Level AA). Messages that are not controls, such as "Saved", need to reach assistive software by another route.
• 3.3.2 Labels or Instructions (Level A). A field’s label is usually its accessible name.

Questions people ask

All WCAG 2.2 criteria, in plain words