wcag

WCAG 4.1.2 Name, Role, Value: What It Means, Failures and Fixes

WCAG 4.1.2 Name, Role, Value: What It Means, Failures and Fixes

get in touch

Know where you stand. Know what to work on next.

Tell us what you’re working on and where you need support. Our accessibility specialists can help with audits, remediation, VPAT/ACR, accessible development, and ongoing compliance.

Free 30-minute consultation (opens in new tab)

Free 30-minute call: talk through where you stand, scope a project or get a quote.

Need technical answers now? Book the $100 one-hour consultation to walk through an audit, talk with a developer or review your site live.

Let’s find the barriers before your users do

Indicates a required field.


Your information is kept private and never shared with third parties.

WCAG 4.1.2 Name, Role, Value (Level A) requires every user interface component to expose an accessible name, the correct role, and its current states and values to assistive technology, and to announce when those change. Native HTML controls do this for you; custom widgets built from div, span or ARIA need it added by hand. The wording is the same in WCAG 2.0, 2.1 and 2.2.

HalfAccessible audits are founder-led by Mohammad Shadab Saifi (IAAP CPACC, WAS and CPWA) with more than 10 years of accessibility experience. Below: what 4.1.2 requires, failing vs fixed code, W3C failure techniques, and how to test so custom menus, modals and widgets pass.

WCAG 4.1.2 At A Glance

  • Level A: Required for every WCAG conformance target, including 2.1 AA and 2.2 AA (Source: W3C Understanding 4.1.2)
  • 2.0–2.2: Same Name, Role, Value wording across WCAG 2.0, 2.1 and 2.2 (Source: W3C WCAG 2.2)
  • F59 / F68: Top documented failures: scripted div/span with no role, and controls with no accessible name (Source: W3C Failure Techniques)
  • First Rule: Prefer native HTML; use ARIA only when the native control cannot do the job (Source: W3C First Rule of ARIA)

Choose Your Next Step

Building or fixing custom widgets? Scan a page, dig into related ARIA patterns, or talk through an audit before you spend anything.

Scan For Name And Role Issues (Free tool)

Best for: a quick first look at missing names and basic ARIA problems

Run a free one-page scan on AccessibilityScore.in (powered by axe-core). It is a starting point that complements a manual audit; scanners miss many live-state and keyboard gaps.

Run a free accessibility scan (opens in a new tab)

Learn aria-expanded Next (guide)

Best for: developers wiring accordions, menus and disclosure widgets

aria-expanded is the state 4.1.2 expects to update when a control opens or closes. See working examples and common mistakes.

Read the aria-expanded guide

Free 30-Minute Call

Best for: first conversations, where you stand, and getting a quote

Tell us which widgets fail Name, Role, Value. We explain where you stand and how a fixed-price audit fits before you commit.

Book a Free 30-Min Call (opens in a new tab)

$100 Technical Hour

Best for: teams that need technical answers now

A hands-on session to walk an audit finding, talk with your developer, or review a live component’s name, role and state.

Book a $100 consultation

What is WCAG Success Criterion 4.1.2?

WCAG Success Criterion 4.1.2, known as “Name, Role, Value”, is a Level A requirement in the Web Content Accessibility Guidelines (WCAG). It falls under the principle of Robust, Guideline 4.1 Compatible, and makes sure assistive technologies can accurately interpret and operate user interface components. Because it is Level A, it is part of every conformance target, including the WCAG 2.1 and 2.2 AA levels that laws and contracts usually reference.

The full text in WCAG 2.2 reads:

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.

W3C’s Understanding 4.1.2 notes that the criterion is mainly aimed at authors who build or script their own components. Standard HTML controls used according to the specification already meet it.

Breaking Down the Requirements

  • Name: the text that identifies the component to the user, such as the text on a button, a form field’s label, or the alt text of an image link. Screen readers announce it, and voice control users say it to activate the control. The APG guide to providing accessible names and descriptions explains where names come from.
  • Role: what the component is, such as button, link, checkbox, tab or slider. The role tells assistive technology how the element behaves and which keys a user can expect to work.
  • States, properties and values: the component’s current condition, such as checked or unchecked, expanded or collapsed, pressed, selected, the chosen option in a list, or the text in an input. Two requirements apply here: if a user can change it, assistive technology must be able to set it too (programmatically settable), and when it changes, assistive technology must be told (notification of changes).

By exposing all of this through the browser’s accessibility tree, a component can be understood and operated by screen readers, voice control software and switch access tools, regardless of how it looks on screen.

WCAG 4.1.2 in WCAG 2.2 and the Laws That Use It

Success criterion 4.1.2 did not change in WCAG 2.2. Its neighbour did: 4.1.1 Parsing is obsolete and removed from WCAG 2.2, because browsers now repair markup errors and assistive technologies rely on the browser instead of parsing HTML themselves. W3C’s Understanding 4.1.1 notes that many issues that used to fail Parsing, such as a duplicated ID that breaks an aria-labelledby reference, now fail Info and Relationships (1.3.1) or Name, Role, Value (4.1.2) instead. That makes 4.1.2 even more important in a WCAG 2.2 audit.

Because it is Level A, 4.1.2 is part of every standard that legal requirements point to:

  • ADA Title II (US state and local government): the DOJ’s 2024 web rule makes WCAG 2.1 Level AA the technical standard for web content and mobile apps. An interim final rule published on April 20, 2026 moved the compliance dates to April 26, 2027 for entities serving 50,000 people or more and April 26, 2028 for smaller entities and special districts. See our DOJ Title II deadline guide.
  • ADA Title III (US businesses): there is no DOJ technical rule for private websites, but the DOJ’s web accessibility guidance points businesses to WCAG and the Section 508 Standards as helpful guidance.
  • Section 508 (US federal ICT): the Revised 508 Standards incorporate WCAG 2.0 Level A and AA by reference, so 4.1.2 applies to federal websites, software and documents.
  • EN 301 549 and the European Accessibility Act: EN 301 549 V3.2.1 applies 4.1.2 to web pages in clause 9.4.1.2 and to non-web software in clause 11.4.1.2. Our EN 301 549 V4.1.1 guide covers what the new version changes.

Why is this important?

This criterion ensures that people who use assistive technology can understand and operate every control on a page. Without the right name, a screen reader announces only “button”. Without the right role, a clickable div sounds like plain text, so users never know it can be activated. Without state, a user ticks a box or opens a menu and hears nothing back, so they cannot tell whether it worked. Any one of these can make a form, checkout or app impossible to complete.

First Rule of ARIA: Semantic HTML First

The easiest way to meet WCAG success criterion 4.1.2 is to use native HTML elements. A <button>, <a href>, <input type="checkbox"> or <select> comes with a role, a way to take a name, built-in states and keyboard support. That is the W3C’s first rule of ARIA.

When you do add a role with ARIA, remember that a role is a promise. role="button" tells a screen reader user “this is a button, press Enter or Space”, but it adds no behaviour. You have to make the element focusable and handle those keys yourself. The ARIA Authoring Practices Guide (APG) documents the expected keyboard behaviour for each widget pattern.

Examples: Failing and Fixed Code

Standard Button

<!-- Fails: no role, not focusable, no keyboard support -->
<div class="btn" onclick="submitForm()">Submit</div>

<!-- Passes: native button -->
<button type="submit">Submit</button>

The name is “Submit” and the role is “button”. A plain button has no state to report: it is not “selected” or “unselected”, it is simply activated. State only comes in when the button toggles something, as in the examples below.

Icon-Only Button

<!-- Fails: role is button, but there is no name -->
<button type="button"><svg aria-hidden="true">...</svg></button>

<!-- Passes: name supplied with aria-label -->
<button type="button" aria-label="Close dialog"><svg aria-hidden="true">...</svg></button>

The name is “Close dialog” and the role is “button”. Our aria-label guide covers when to use it, and our aria-labelledby guide shows how to name a control from visible text.

Checkbox

<!-- Best: native checkbox exposes name, role and state automatically -->
<input type="checkbox" id="terms">
<label for="terms">I agree to the terms</label>

<!-- Custom checkbox: you must supply role, name, state and keyboard support -->
<span role="checkbox" aria-checked="false" tabindex="0" aria-labelledby="terms-label"></span>
<span id="terms-label">I agree to the terms</span>

The name is “I agree to the terms”, the role is “checkbox”, and the state is checked or not checked. For the custom version, your script must flip aria-checked between "true" and "false" on click and on the Space key; that update is the “notification of changes” the criterion requires.

Toggle Button

<button type="button" aria-pressed="false">Mute</button>

The name is “Mute”, the role is “toggle button” and the state is pressed or not pressed. Keep the label stable and change aria-pressed; if you also swap the text to “Unmute”, users hear a confusing double message.

Accordion Header

<h3>
  <button type="button" aria-expanded="false" aria-controls="faq1">Shipping</button>
</h3>
<div id="faq1" hidden>...</div>

The name is “Shipping”, the role is “button” and the state is collapsed or expanded. Update aria-expanded whenever the panel opens or closes; our aria-expanded guide walks through the full pattern.

Tabs

<div role="tablist" aria-label="Plans">
  <button role="tab" aria-selected="true" aria-controls="p1" id="t1">Monthly</button>
  <button role="tab" aria-selected="false" aria-controls="p2" id="t2" tabindex="-1">Yearly</button>
</div>

Here “selected” is the right word: aria-selected tells users which tab is active. The APG tabs pattern also expects arrow-key navigation between tabs.

Switch

<button type="button" role="switch" aria-checked="true">Email notifications</button>

The name is “Email notifications”, the role is “switch” and the state is on or off. A switch uses aria-checked, not aria-pressed; your script must flip it when the user presses Enter or Space. The APG switch pattern shows the full behaviour.

Custom Slider

<span id="vol-label">Volume</span>
<div role="slider" tabindex="0" aria-labelledby="vol-label"
     aria-valuemin="0" aria-valuemax="100" aria-valuenow="40" aria-valuetext="40 percent"></div>

The name is “Volume”, the role is “slider” and the value is “40 percent”. Update aria-valuenow (and aria-valuetext when the number alone is unclear) every time the arrow keys or a drag change the value. A native <input type="range"> does all of this for you. See the APG slider pattern.

Common 4.1.2 Failures

Failure What to do instead
Clickable div or span Click handlers on generic elements give no role and no keyboard access. Use a <button> or <a href>.
Missing name Icon buttons, empty links and unlabeled form fields are announced as just “button”, “link” or “edit text”. Add a visible label or accessible name.
Wrong role A link styled as a button that performs an action, or role="menu" on ordinary site navigation, sets the wrong expectations. Match the role to the behaviour.
Stale states A toggle, accordion or custom checkbox changes visually while aria-pressed, aria-expanded or aria-checked stays the same. Update state when the UI changes.
Placeholder as the only name Placeholder text is not a reliable label and disappears on input. Use a <label>.
Broken references aria-labelledby pointing to a missing or duplicated ID leaves the control unnamed or wrongly named. Point to a unique, existing ID.

W3C Failure Techniques for 4.1.2

W3C documents specific failures of 4.1.2. Auditors use them to classify issues, and they make a useful self-check:

Technique What it covers
F59 A div or span made into a control with script but given no role.
F68 A control with no programmatically determined name.
F111 A control with visible label text but no accessible name (also fails 1.3.1 and 2.5.3).
F15 Custom controls that do not use the accessibility API, or use it incompletely.
F79 The focus state of a component cannot be determined, or focus changes are not reported.
F86 A multi-part field, such as a phone number split into three inputs, without a name for each part.
F89 An image that is the only content of a link has no accessible name (also fails 2.4.4).
F20 A text alternative is not updated when the non-text content changes.
F42 Links emulated with script on elements that are not links.

How to Implement Success Criterion 4.1.2

  • Use semantic HTML: buttons, links, inputs, checkboxes and select elements have names, roles and values built in. Avoid generic div and span elements where a semantic element will do.
  • Provide labels: use <label> for form fields, visible text inside buttons and links, and aria-label or aria-labelledby only for custom elements or icon-only controls.
  • Implement ARIA correctly: for custom widgets, follow the matching APG pattern: the right role, a name, the right state attribute (aria-checked, aria-pressed, aria-expanded, aria-selected, aria-valuenow/aria-valuetext) and the keyboard support the role promises. Use aria-current for the current page in navigation and pagination. Our ARIA essentials guide covers the basics, and the interactive aria-pressed, aria-selected and button role references in our Developer Playground let you try each state.
  • Manage dynamic content: when a name, state or value changes, update the attribute in the same code that changes the visual state, so assistive technology is notified.
  • Test thoroughly: see below.

How to Test for Success Criterion 4.1.2

Testing for this criterion needs a mix of automated tools and manual checks:

  • Automated accessibility checkers: tools like axe DevTools, WAVE or Google Lighthouse flag missing names, invalid ARIA attributes and some role problems. They cannot judge whether a name makes sense or whether states update. Our automated accessibility testing guide explains what they catch.
  • Screen reader testing: with NVDA, JAWS or VoiceOver, move to each control and confirm the name, role and state are announced, then operate it and check that the new state is announced. See our screen reader testing guide.
  • Keyboard testing: every element with an interactive role must be reachable and operable with the keys its role implies. Our manual keyboard testing guide covers the routine.
  • Browser developer tools: the Accessibility panel in Chrome, Edge and Firefox shows each element’s computed name, role and states. Watch it while you interact with a custom widget.
  • Manual review: check custom widgets against the APG pattern for their role. WebAIM’s WCAG 2 checklist and MDN’s guide to the Robust principle are useful references while you review.

WCAG 4.1.2 Testing Checklist

  • Every button, link, form field and custom widget has an accessible name that includes its visible label text.
  • Every interactive element has the right role: actions are buttons, navigation is links, and custom widgets use the role of their APG pattern.
  • Toggles, switches, checkboxes, accordions, tabs and menus expose their state (aria-pressed, aria-checked, aria-expanded, aria-selected), and it updates the moment the screen changes.
  • Sliders, spin buttons and progress bars expose their current value.
  • Every aria-labelledby and aria-describedby reference points to an ID that exists once.
  • NVDA, JAWS or VoiceOver announce name, role and state on focus, and announce the new state after activation.
  • Each control works with the keys its role promises, with no mouse.

Why WCAG 4.1.2 Failures Show Up In Accessibility Audits

Name, Role, Value is Level A, so it appears in nearly every WCAG 2.2 AA audit report. The failures that cost teams the most time are rarely the ones a scanner flags on a bare <button>. They sit in custom menus, modal dialogs, date pickers, carousels, filter drawers and checkout steppers: components that look interactive but never expose a name, role or live state to the accessibility tree.

Automated tools such as axe, WAVE and Lighthouse reliably catch missing names and invalid ARIA. They cannot tell whether a name is meaningful, whether aria-expanded flipped after a click, or whether a role promised keyboard behaviour the script never added. That is why W3C’s Understanding 4.1.2 and the ARIA Authoring Practices Guide both expect manual keyboard and screen reader checks alongside automation.

What Auditors Check On Every Interactive Control

  • Accessible name present and includes the visible label (4.1.2 and 2.5.3).
  • Correct role for the behaviour (button vs link vs tab vs switch).
  • State or value updates in the same code path that changes the screen (aria-checked, aria-pressed, aria-expanded, aria-selected, aria-valuenow).
  • Notification of changes reaches assistive technology on activation.
  • Keyboard support matches the role the component claims.

Conclusion

WCAG success criterion 4.1.2 is fundamental for making websites and applications usable by everyone. Use native HTML first, give every control a clear name, keep roles honest by adding the keyboard behaviour they promise, and update states in the same code that changes the screen. Test with automated tools, a keyboard and a screen reader, and you will catch the failures that matter most.

Get Your Components Tested for 4.1.2

Name, Role, Value failures hide in custom menus, modals, date pickers, carousels and checkout steps, where automated scanners can only catch part of the problem. HalfAccessible has more than 10 years of accessibility experience. Audits are founder-led by Mohammad Shadab Saifi (IAAP CPACC, WAS and CPWA) and done by hand with NVDA, JAWS, VoiceOver and TalkBack, mapped to WCAG 2.2 AA.

Already know the problems? Our accessibility remediation service fixes them directly in your code, and our accessible React development and accessible WordPress development teams build components that pass 4.1.2 from the start. Not sure which package fits? Request a free accessibility needs assessment or see pricing.

Frequently Asked Questions

What level is WCAG 4.1.2?

Level A, the minimum level. It applies at every conformance target, so a site claiming WCAG 2.1 AA or WCAG 2.2 AA must meet it.

What does name, role, value mean in WCAG?

The name is what a control is called (for example “Search”), the role is what kind of control it is (button, link, checkbox, tab, slider) and the value or state is its current condition (checked, expanded, selected, 40 percent). Assistive technology reads all three from the browser’s accessibility tree, so they must be set in code, not just shown visually.

Do native HTML elements pass 4.1.2 automatically?

Their role and state handling passes when they are used according to the HTML specification, but you still need to give them a name: a button with only an icon, or an input without a label, fails.

Is 4.1.2 only about ARIA?

No. ARIA is one way to expose names, roles and states, mostly for custom components. Most pages meet the criterion with well-structured HTML and only a few ARIA attributes.

Did WCAG 4.1.2 change in WCAG 2.2?

No, the wording is the same in WCAG 2.0, 2.1 and 2.2. What changed is that 4.1.1 Parsing was removed from WCAG 2.2. W3C notes that many issues that used to fail Parsing, such as duplicate IDs that break a label reference, now fail 1.3.1 Info and Relationships or 4.1.2 instead.

What is the difference between WCAG 4.1.2 and 4.1.3?

4.1.2 Name, Role, Value (Level A) covers the components themselves: their name, role and state, and announcing changes to them. 4.1.3 Status Messages (Level AA) covers messages such as “3 results found” or “Item added to cart” that appear without moving focus and must be announced through a live region.

How is 4.1.2 related to 2.5.3 Label in Name?

4.1.2 requires a control to have an accessible name. 2.5.3 Label in Name (Level A) requires that name to contain the visible label text, so voice control users can say what they see. A button that shows “Send” but is named “Submit form” can pass 4.1.2 and still fail 2.5.3. W3C failure F111 covers a visible label with no accessible name at all.

Which automated tools catch 4.1.2 failures?

Tools such as axe DevTools, WAVE and Lighthouse reliably catch missing names on buttons, links and form fields, invalid ARIA attributes and some missing roles. They cannot tell whether a name is meaningful or whether a state updates after a click, so keyboard and screen reader testing is still needed.

Does 4.1.2 apply to mobile apps and PDFs?

Yes. The ADA Title II web rule covers mobile apps as well as websites, EN 301 549 applies the same requirement to non-web software in clause 11.4.1.2, and in PDFs form fields need a name, role and value through tags and field properties (W3C technique PDF12). VoiceOver and TalkBack should announce every control in an app with its name, role and state.

How can I get my site or app tested for WCAG 4.1.2?

HalfAccessible audits are founder-led by Mohammad Shadab Saifi (IAAP CPACC, WAS and CPWA), with every component checked by hand using NVDA, JAWS, VoiceOver and TalkBack. A Quick Audit is $500 for up to 5 templates, the Complete Audit is $2,000 for up to 25 templates with a re-test, and a one-hour technical consultation is $100 (audit walkthrough, developer Q&A or live issue review). First conversations are a free 30-minute call to understand where you stand and get a quote. See pricing or request a free needs assessment.

Can aria-describedby replace an accessible name under 4.1.2?

No. An accessible description from aria-describedby is supplemental information. WCAG 4.1.2 requires a programmatically determinable name that identifies the control. If the accessible name is empty, the control fails 4.1.2 even when a description is present. Use a <label>, visible text, aria-label or aria-labelledby for the name.

What do auditors look for when testing WCAG 4.1.2?

Auditors check every interactive control for a clear accessible name, the correct role, live state or value updates, and keyboard behaviour that matches the role. They map failures to W3C techniques such as F59, F68 and F111, re-test after fixes, and confirm screen readers announce name, role and state on focus and after activation. Automated scanners help with missing names; state and meaningful names still need NVDA, JAWS or VoiceOver.

How much does a WCAG 4.1.2 focused accessibility audit cost?

HalfAccessible uses fixed packages, not hourly rates: a $500 Quick Audit (up to 5 templates), a $2,000 Complete Audit (up to 25 templates with a re-test), and a $2,000 Shopify Accessibility Audit. A $100 one-hour technical consultation is for teams that need a live walkthrough of failing components. New projects usually start with a free 30-minute call. Full details are on our pricing page.

Does failing 4.1.2 create legal risk under ADA or the EAA?

Yes. Because 4.1.2 is Level A, it is part of WCAG 2.1 AA (ADA Title II web rule) and WCAG 2.0 AA (Revised Section 508), and EN 301 549 applies the same requirement for the European Accessibility Act. Missing names, wrong roles or stale states on core journeys such as login, checkout or account forms are common findings in demand letters and compliance audits. Fixing them early is cheaper than remediating under a deadline.

Should I book the free 30-minute call or the $100 technical consultation for 4.1.2 issues?

Book the free 30-minute Calendly call for a first discussion: understand where you stand, scope a project and get a quote. Choose the $100 one-hour consultation when you need a technical working session now, such as walking through an audit finding, talking with your developer, or reviewing a live component’s name, role and state. Both offers stay available; pick by how ready you are, not by price alone.

Can AccessibilityScore.in replace a manual WCAG 4.1.2 audit?

No. AccessibilityScore.in (powered by axe-core) is a free starting point that surfaces missing names and basic ARIA issues. It complements a manual audit; it cannot confirm whether aria-expanded flipped after a click, whether a name is meaningful, or whether a role’s keyboard behaviour actually works. For custom widgets, use a free scan first, then a founder-led manual audit with NVDA, JAWS and VoiceOver.

Written by Shadab Saifi Published Last updated

Share

link