WCAG 4.1.2 Name, Role, Value requires that every interactive control — buttons, links, form fields, toggles, custom widgets — expose three things to assistive technology in code: its name (what it’s called), its role (what type of control it is), and its value or state (checked, expanded, selected), with a notification whenever any of those change.
What 4.1.2 actually says
The official wording from the W3C Understanding document is precise: for all user-interface components, “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.”
Break that into plain terms:
- Name — the text a screen reader announces to identify the control (“Search”, “Add to cart”). It is often the visible label, but it must be exposed in the markup, not just painted on screen.
- Role — what kind of control it is: a button, link, checkbox, tab, menu. Roles tell assistive tech how the user can operate the thing.
- Value / state — the current condition the user can set or read: a checkbox that’s checked, an accordion that’s expanded, a slider at 40%, a tab that’s selected.
- Notification of changes — when a panel expands or a toggle flips, the assistive technology must be told, so the user isn’t left with a stale picture of the page.
It is a Level A criterion — the most basic tier — and part of the Robust principle in POUR: content must work reliably with the tools people actually use.
Who it affects
This criterion is the make-or-break point for anyone who doesn’t drive a page with a mouse and a pair of working eyes:
- Screen reader users (JAWS, NVDA, VoiceOver) hear the role and name. An unnamed icon button is announced as just “button” — or skipped entirely — so a blind user can’t tell what it does.
- Voice-control users (Dragon, macOS/Windows Voice Control) say a control’s name to click it: “click Submit”. No name means no voice command works.
- Switch and keyboard users rely on roles to expose the control as a focusable, operable target.
- Screen-magnifier users depend on state notifications to know something off-screen just changed.
Standard HTML elements — <button>, <a href>, <input> with a <label> — satisfy 4.1.2 for free. Problems start the moment a team builds a custom control out of generic elements and forgets to wire up the accessibility plumbing.
Concrete failures and their fixes
The W3C catalogues specific documented failures of this criterion. These are the ones we see most during remediation.
Clickable div with no role (Failure F59)
A <div> or <span> with a click handler but no role is invisible to assistive tech.
<!-- Fails 4.1.2: no role, no name, no keyboard support -->
<div class="btn" onclick="addToCart()">Add to cart</div>
<!-- Fix: use a real button -->
<button type="button" onclick="addToCart()">Add to cart</button>A native <button> brings its role, focusability, and Enter/Space activation with it. If you genuinely can’t use one, you must add role="button", tabindex="0", a name, and key handlers yourself — which is exactly why the native element is the better choice.
Control with no programmatic name (Failure F68 / F86)
A field whose only “label” is a placeholder, or an icon button with no text, has no name.
<!-- Fails: placeholder is not a name; it vanishes on input -->
<input type="text" placeholder="Email">
<!-- Fix: associate a real label -->
<label for="email">Email</label>
<input type="text" id="email">
<!-- Icon-only button fix: -->
<button type="button" aria-label="Close dialog">
<svg aria-hidden="true">...</svg>
</button>F86 covers multi-part fields too — a phone number split into three boxes needs a name on each box, not one label for the group.
Icon link with no accessible name (Failure F89)
An image used as the only content of a link must carry alt text, or the link announces as nothing usable (often the raw URL).
<!-- Fails: link has no perceivable name -->
<a href="/cart"><img src="cart.svg"></a>
<!-- Fix: give the image meaningful alt text -->
<a href="/cart"><img src="cart.svg" alt="Shopping cart"></a>State that never updates (Failure F79)
A custom accordion or menu that toggles visually but never updates aria-expanded leaves screen reader users guessing.
<!-- State must change in code when the panel opens -->
<button aria-expanded="false" aria-controls="faq1">Shipping FAQ</button>
<!-- on click, set aria-expanded="true" -->The broader pattern — building custom widgets that simply don’t talk to the accessibility API — is documented as failure F15. Getting roles, names, and states right is the core of our ARIA labels and roles guide.
How to test for 4.1.2
You can find most violations quickly, but the final word comes from a real screen reader.
- Run an automated scan. axe, WAVE, or Lighthouse flag empty buttons, empty links, and unlabeled fields fast. A free Curbcut scan surfaces these in minutes.
- Tab through every control. Each interactive element should receive focus and announce a sensible name and role.
- Inspect the accessibility tree. Chrome and Firefox DevTools show the computed name and role for any element — if the Name field is blank, you have a 4.1.2 problem.
- Drive it with a screen reader. Turn on VoiceOver (Mac) or NVDA (Windows) and operate your menus, modals, tabs, and forms. If it says “button” with no name, or never announces “expanded”, that’s a failure.
- Try voice control. If you can’t click a control by speaking its visible label, the name is missing or wrong.
Automated tools catch the obvious empties but can’t judge whether a name is correct or whether state updates fire — which is why accessible forms and custom widgets always need a human pass. See how the tools that consume this data behave in our screen readers guide.
Why 4.1.2 is the failure plaintiffs and regulators name first
When a screen-reader tester documents a website complaint, the controls they can’t name or operate are the evidence, and those are 4.1.2 failures. The clearest example is the U.S. Department of Justice’s own enforcement: in its settlement with grocery delivery service Peapod, the DOJ’s agreement found that on peapod.com “images, buttons, and form fields are unlabeled or have inaccurate alternative text” and “pop-up modal windows are not reported to screen readers.” That is the Name, Role, Value criterion described almost word for word — an unnamed button, an unlabeled field, a modal whose role and state never reach assistive tech. The remedy DOJ required was not a disclaimer or a widget; it was conformance of the whole site to WCAG, achieved by labelling the controls in code.
The same barriers drive private litigation. Checkout buttons a screen reader announces as bare “button”, search fields with no programmatic label, and “Add to cart” controls built from clickable <div>s are among the most-cited issues in ADA website lawsuits, and they are easy for a plaintiff’s tester to capture because the proof is a single empty Name field in the accessibility tree. The scale of the exposure is well documented: UsableNet’s 2024 year-end report counted over 4,000 ADA digital-accessibility lawsuits in that year. Because 4.1.2 is a Level A criterion — the floor of WCAG 2.1 AA, the benchmark DOJ adopted for state and local government sites in its 2024 web rule — a control assistive tech can’t operate isn’t a near-miss; it fails the lowest bar in the standard.
This is also where accessibility overlays fail most visibly. An overlay tries to infer a missing name from nearby text and to bolt a role onto a generic element after the page loads, but it cannot reliably know that your custom dropdown is “expanded” or that a three-box phone field needs a name on each input — exactly the dynamic Name/Role/Value plumbing this criterion is about. That guesswork is a core reason overlays don’t work for 4.1.2, and UsableNet found more than a quarter of 2024 lawsuits targeted sites that already had a widget installed. Curbcut is deliberately anti-overlay: our accessibility consultants write the correct <button>, <label for>, aria-label, and live aria-expanded/aria-checked states directly into your source, the only fix that survives a real screen reader and a tester’s report.
This is general information, not legal advice. For your specific exposure, consult a qualified ADA attorney.
Fixing the names, roles, and states on your controls
4.1.2 is the criterion you can verify in one afternoon and the one most likely to be quietly broken everywhere: every custom dropdown, icon button, toggle, tab strip, and split form field is a place where the name, role, or state can silently fail to reach a screen reader. The good news is that the fixes are concrete and mechanical — swap a clickable <div> for a <button>, tie each input to a real <label for>, give icon-only controls an aria-label, and wire aria-expanded / aria-checked to update the moment the widget changes.
If you’re not sure which of your controls announce nothing, start by opening the accessibility tree in DevTools, or run a free Curbcut scan to surface the empty buttons, empty links, and unlabeled fields automatically. From there, an accessibility audit inventories every unnamed control and stateless widget on the site, and our remediation team adds the missing names, roles, and states in your code — checked against JAWS, NVDA, and VoiceOver, not guessed at by an overlay. For the markup patterns themselves, the ARIA labels and roles guide and the accessible forms guide walk through the exact code.