A Name, Role, Value failure means assistive technology cannot tell what a control is called, what kind of control it is, or what state it is in. WCAG success criterion 4.1.2, Name, Role, Value, is a Level A requirement that every user interface component expose three things a program can read: its name, its role, and, where the user can change it, its current value and state, with changes reported to assistive technologies (W3C). To fix a 4.1.2 issue you work through those three in order. First, give the control a real accessible name: visible text, a <label for>, aria-labelledby, or aria-label. Second, give it the correct role. The shortcut here is to use the native HTML element (<button>, <input>, <a>, <select>) whenever one exists, because native controls carry name, role, and value for free (W3C); reach for ARIA only when you are building a widget HTML does not have. Third, expose state and value with the matching properties (aria-expanded on a disclosure, aria-checked on a custom checkbox, aria-valuenow on a slider) and keep them updated as the user acts. The rest of this guide is those three moves, the failures that break each one, and what a scanner can confirm for you.
What does WCAG 4.1.2 actually require?
The criterion reads: "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" (W3C). Three nouns do the work.
Name is the text a program uses to identify the control to the user, the label a screen reader reads out. Role is what the control is: a button, a checkbox, a tab, a slider. Value and state are the parts that change: checked or unchecked, expanded or collapsed, the position on a slider. The last clause matters as much as the first. If a menu opens but nothing tells assistive technology it opened, the control still fails, because notification of the change never reached the screen reader.
W3C is direct about who this is for: "This success criterion is primarily for web authors who develop or script their own user interface components... standard HTML controls already meet this success criterion when used according to specification" (W3C). That is the whole fix strategy in one line. A <button> is a button to every screen reader without any ARIA. A <div> styled to look like one says nothing until you supply all three parts by hand, and get every one right.
How do I fix a missing accessible name?
Give the control text that a program can read. There are four common ways, and you pick by what is already on the page.
- Visible text inside the element.
<button>Save</button>has the accessible name "Save" for free. This is the first choice whenever the control has a text label. - A
<label>tied to the input.<label for="email">Email</label><input id="email">names the field. Theforattribute must match the input'sid; a label that only wraps or sits near the field, with no association, does not count. aria-labelledbypointing at other visible text on the page. Use this when the name already exists in the DOM (a heading, a legend) and you want to reuse it rather than duplicate it.aria-labelwhen there is no visible text to reference, typical for icon-only controls. A search field with just a magnifying-glass icon getsaria-label="Search".
Three failures cluster here. F68 is a control with no programmatically determined name at all: the unlabeled input, the icon button with no text (W3C). F89 is narrower and very common: an image that is the only thing inside a link, with no alt text, so the link has no name. The fix is alt on the image describing where the link goes. F111 is the quiet one: a control has visible label text but no accessible name, because the label was never associated. A sighted user reads "Phone number" next to the box; a screen reader announces "edit text," blank. The visible label and the accessible name are two different things, and 4.1.2 is about the second.
One rule keeps you out of trouble: prefer real text or <label> over ARIA. WebAIM's guidance is that when text in another element can be referenced, use aria-labelledby rather than aria-label, and native association over either (WebAIM). ARIA names are invisible, so they drift: someone edits the visible text and the aria-label still says the old thing.
How do I give a component the right role?
Use the native element. This is the first rule of ARIA, and it is worth quoting exactly: "If you can use a native HTML element or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so" (W3C). A native <button> is announced as a button, is focusable, fires on Enter and Space, and reports its disabled state — none of which you wrote.
The failures on the role side come from ignoring that. F59 is scripting a <div> or <span> into a control without giving it a role, so assistive technology has no idea it is interactive (W3C). F42 is emulating a link with a click handler on a non-link element. The fix for both is usually deletion, not addition: replace the <div onclick> with a <button> or an <a href>, and the role, focus, and keyboard behavior arrive together.
When no native element fits (a tablist, a tree, a slider), you add role, and you owe the full contract. The ARIA Authoring Practices Guide puts it plainly: "A role is a promise." Declaring role="checkbox" promises that the element also manages aria-checked, takes focus, and toggles on Space, because the browser no longer does any of that for you. The same guide's blunter heading is "No ARIA is better than Bad ARIA" (W3C). A half-built role="checkbox" that never updates aria-checked reads as a checkbox stuck on one value, which is worse than a plain checkbox would have been.
How do I expose state and value?
Match the ARIA state or property to the role, and update it in the same code that changes the visual. A disclosure button uses aria-expanded="false" and flips it to "true" when the panel opens. A custom checkbox uses aria-checked. A toggle uses aria-pressed. A slider uses aria-valuenow, with aria-valuemin and aria-valuemax for the range. A control the app disables gets aria-disabled="true" (or, on a native control, the disabled attribute, which also removes it from the tab order).
The part teams miss is the third clause of 4.1.2, notification of change. Setting aria-expanded="true" once at render is not enough; it has to become "false" when the user collapses the panel, in the click handler, every time. F79 covers the related focus case: the focus state of a component is not programmatically determinable, or no notification of a focus change is available (W3C). F86 is the multi-part field trap: a phone number split into three inputs where each part has no name, so a screen reader reads "edit text, edit text, edit text." Each box needs its own name: area code, prefix, line number.
Here is the shape of a correct custom disclosure, state included:
<button aria-expanded="false" aria-controls="panel1">
Shipping options
</button>
<div id="panel1" hidden>…</div>
btn.addEventListener('click', () => {
const open = btn.getAttribute('aria-expanded') === 'true';
btn.setAttribute('aria-expanded', String(!open));
panel.hidden = open;
});
The aria-expanded value and the hidden attribute change on the same line of logic. That is the habit to build: state and appearance move together, or they drift apart and the screen reader lies.
What are the most common 4.1.2 failures?
Most real-world 4.1.2 defects are a short list. This table maps each to its fix.
| Failure | What it looks like | Fix |
|---|---|---|
| F68 | Input or icon button with no accessible name | <label for>, aria-label, or aria-labelledby |
| F89 | Image-only link with no alt | alt describing the link destination |
| F111 | Visible label text, but not associated | Tie the label to the control (for/id) |
| F59 | <div>/<span> scripted into a control, no role | Use a native <button>/<a>, or add the role |
| F42 | Click handler faking a link | Real <a href> |
| F79 | State (focus, expanded) not exposed or not updated | Update the matching ARIA state on every change |
| F86 | Multi-part field with unnamed parts | Name each input separately |
Source for the failure techniques: W3C Understanding SC 4.1.2. The pattern across all of them is the same. Native HTML gets name, role, and value right by default; every failure above is a place where someone left the native element behind and did not finish the job.
Can a scanner catch Name, Role, Value problems?
Partly, and it is worth knowing which part. A scanner is good at the yes/no half of 4.1.2: does this input have any accessible name, does this role="checkbox" carry an aria-checked, is this button empty. Missing names and missing required attributes are machine-detectable, which is why 4.1.2 shows up so often in automated reports. Across more than 2,000 audits, Deque found automation caught about 57% of issues by volume, with other estimates near 30% by the share of success criteria a tool can evaluate at all (Deque). Name, Role, Value straddles that line.
What a tool cannot judge is whether the name is right. aria-label="button" passes the presence check and tells the user nothing. A role that is technically valid but wrong for the control, say role="menu" on a set of page links, will not trip a scanner either. And "does the state update when the user acts" needs someone to operate the widget with a screen reader and listen. So run the scanner to clear the mechanical failures in bulk; it finds the empty inputs and the nameless icon buttons fast. Then keyboard through the custom components yourself, because the meaningful-name and does-the-state-change questions live in the half automation cannot reach.
The one opinion I hold on this: overlays and auto-fix widgets that claim to patch these issues at runtime are selling the presence check as if it were the quality check. Injecting an aria-label you never see does not make it correct, and it hides the problem from the next developer. Fix Name, Role, Value in the markup, where the next person can read it. WCAG 4.1.2 is incorporated into EN 301 549, the European standard behind the EAA, so getting it right is part of the legal bar in the EU, not only good practice.
Frequently asked questions
What is a Name, Role, Value failure in one sentence?
It is a user interface control that assistive technology cannot fully identify — its name, its type (role), or its current state and value is missing or not exposed to a program, so a screen reader user cannot tell what the control is or does.
Is WCAG 4.1.2 a Level A requirement?
Yes. Name, Role, Value is a Level A success criterion, the minimum conformance level, so it applies to any site claiming even the lowest WCAG conformance (W3C).
Do native HTML elements meet 4.1.2 automatically?
Standard HTML controls used according to spec already satisfy 4.1.2 (W3C). A <button>, <input>, or <select> exposes its role, name, and value without any ARIA. The criterion is mainly aimed at custom, scripted components.
When should I use ARIA to fix a 4.1.2 issue?
Only when no native element provides the semantics you need. The first rule of ARIA is to use native HTML when you can, and add ARIA roles, states, and properties only for widgets HTML lacks, such as tabs, trees, or sliders (W3C). If you declare a role, you must also supply its states and keyboard behavior.
What is the difference between a visible label and an accessible name?
A visible label is the text a sighted user sees; the accessible name is the text a program can read for the control. Failure F111 is the case where a control shows a label but has no accessible name because the two were never associated (W3C).
Find the controls with no accessible name on your site
The quickest start is to see which controls on your pages have no accessible name or no role at all, then work through the custom widgets by hand. Run a free scan to surface the machine-detectable 4.1.2 failures across your key pages, and use our WCAG checklist for the manual checks a scanner cannot make: meaningful names, correct roles, and state that actually updates. The scanner finds the empty controls; you make them mean something.
Pavel Charkasau, founder, wcagc.com. Last updated 30 July 2026.
Sources
- Understanding SC 4.1.2: Name, Role, Value, W3C WAI — the Level A criterion, its definitions, the scope note, and the failure techniques (F68, F89, F111, F59, F42, F79, F86). Accessed 30 July 2026.
- Using ARIA, W3C — the first rule of ARIA: use native HTML before repurposing an element with a role. Accessed 30 July 2026.
- ARIA Authoring Practices Guide, Read Me First, W3C WAI — "A role is a promise" and "No ARIA is better than Bad ARIA." Accessed 30 July 2026.
- Introduction to ARIA, WebAIM — providing accessible names and preferring native association over ARIA labels. Accessed 30 July 2026.
- Automated testing identifies 57% of accessibility issues, Deque — automated coverage figures. Accessed 30 July 2026.