4.1.2 Name, Role, Value

Level A
Robust
Since WCAG 2.0

Summary

Every interactive component must expose three things to assistive technology: a name (what it is called), a role (what kind of thing it is), and its state or value (checked, expanded, selected, the current setting). When any of these change, assistive technology must be told. A screen reader user who lands on a control hears something like "Notifications, switch, on": name, role, state. If any part of that announcement is missing or wrong, the user is guessing.

Native elements give you all of this for free. A <button>, a UISwitch, a Material checkbox: the platform supplies the role and the state plumbing, and the visible label usually supplies the name. Custom components must earn it. The moment a team builds a button out of a div, a toggle out of two images, or a tab bar out of styled views, every piece of that announcement has to be wired up by hand, and this criterion is where the wiring gets graded.

The mental model for testing is the announcement formula itself: for each control, does the screen reader say what it is called, what it is, and what state it is in, and does it re-announce when the state changes?

Official wording

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.

Success Criterion 4.1.2 Name, Role, Value, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, 5 October 2023 (updated 12 December 2024). Copyright © 2023-2024 World Wide Web Consortium. https://www.w3.org/copyright/document-license-2023/. Reproduced unmodified under the W3C Document License.

EN 301 549 mapping

Web pages: Clause 9.4.1.2
Software and native apps: Clause 11.4.1.2 (via Table 11.13)
Closed functionality (kiosks, terminals): Not applicable on closed systems: with no assistive technology to consume it, programmatically determinable name, role, and value information has no consumer.

Clause 9.4.1.2 applies this criterion to web pages unchanged. Clause 11.4.1.2 carries an adapted software version (Table 11.13). On systems closed to assistive technology the requirement is not applicable.

Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.

In practice

Web

Start in the browser's accessibility tree (available in developer tools alongside the DOM inspector). Every interactive element should show a sensible role, a non-empty accessible name, and any relevant state properties. Then confirm with a screen reader pass: tab or swipe to each control and listen for name, role, and state in the announcement.

The classic web failures cluster into four groups. First, div-based buttons: a <div onclick> has no role, so a screen reader announces its text as plain content and the user has no idea it is actionable; it needs role="button" (plus keyboard handling, graded separately). Second, missing accessible names: icon-only buttons with no aria-label, inputs with no associated <label>, links whose only content is a background image. Third, missing state: custom checkboxes without aria-checked, disclosure widgets and accordions without aria-expanded, tab sets without aria-selected, toggle buttons without aria-pressed. The control may look obviously on or off, but the accessibility tree says nothing. Fourth, values that never update: a custom slider needs aria-valuenow (with aria-valuemin and aria-valuemax), and it must update as the user drags, not just render once.

Change notification is usually free when the ARIA attributes are updated in the DOM, because the browser raises the events. The failure mode is state tracked only in JavaScript or CSS classes, with the ARIA attribute set once and never touched.

iOS

VoiceOver builds its announcement from four pieces: the accessibility label (the name), the value (for controls with a setting), the traits (the role, such as button, adjustable, selected), and an optional hint. Testing means listening for those pieces on every control and checking each against what the control actually is.

Custom controls are where it breaks. A tappable view built from a gesture recogniser has no traits, so VoiceOver reads its text and stops: the user double-taps on faith because it never said "button". Adding .button to accessibilityTraits fixes the role; a selected tab or filter chip needs the .selected trait, and VoiceOver announces the change of selection when it is set. Controls with a value, such as steppers and sliders, should carry the .adjustable trait with accessibilityIncrement() and accessibilityDecrement() implemented, and expose the current setting through accessibilityValue so a swipe up or down both changes and announces the value.

In SwiftUI the same information flows through modifiers: .accessibilityLabel, .accessibilityValue, .accessibilityAddTraits(.isButton) and friends. Audit with VoiceOver on a device and cross-check in Accessibility Inspector, which shows the label, value, and traits each element exposes without needing to interpret speech.

Android

TalkBack announces a control's role from its class name or its semantics: a real Button or Switch is announced as one automatically. The anatomy to listen for is content or label, role, and state ("Wi-Fi, switch, on"), followed by usage hints.

The canonical Android failure is the clickable View or TextView with a click listener attached: TalkBack reads it as plain text with no role, so nothing signals that it can be activated. Custom views must populate AccessibilityNodeInfo, typically by setting an appropriate className so the role is announced, marking the node checkable and keeping checked in sync for toggle-style controls, and using stateDescription for states that do not fit the checked model (such as "expanded" or a named mode). State changes need to reach TalkBack as they happen; updating the backing field without firing an accessibility event leaves the announcement stale.

In Jetpack Compose the same contract lives in the semantics system. Clickable modifiers accept a role parameter (Role.Button, Role.Checkbox, Role.Tab), toggleable exposes toggleableState, and stateDescription in a semantics block covers custom states. Test with TalkBack on a device: swipe to each control, listen for name, role, and state, then operate it and confirm the new state is spoken.

Pass and fail examples

Passes:

A native <button>Save</button>: the element supplies the role, the text supplies the name, nothing extra needed.
A custom accordion header with role="button", a text label, and aria-expanded toggled between true and false on activation.
An iOS filter chip that adds the .selected trait when active, so VoiceOver announces "Price, button, selected".
A Compose toggle using Modifier.toggleable with Role.Switch: TalkBack announces the role and the on or off state, and re-announces on change.

Fails:

A clickable div styled as a button: announced as plain text with no role, so the user cannot tell it is interactive.
A custom toggle that swaps between two images to look on or off but exposes no checked state anywhere: it looks stateful and announces nothing.
A tab bar item that highlights visually when active but never sets aria-selected, the .selected trait, or a selected state in semantics: every tab sounds identical.
A custom volume slider that renders aria-valuenow="50" once at mount and never updates it as the user drags.
An icon-only close button with no accessible name: it has a role but the announcement is just "button".

Not a fail under this criterion:

A content image with missing alt text: that is graded under 1.1.1, even though alt text also feeds the accessible name when an image sits inside a control. The boundary is honest but real: 4.1.2 covers user interface components, and a plain informational image is not one.
A purely decorative, non-interactive element with no name: nothing here requires names on things users do not operate.
A custom button that announces perfectly but cannot be reached or activated by keyboard: real failure, wrong criterion (2.1.1 Keyboard).

Commonly confused with

1.1.1 Non-text Content. Text alternatives for content images belong there; 4.1.2 covers controls. The boundary follows the element type: when the control's visual is an image element (an img inside a link or button, or an image input), the missing alternative is filed under 1.1.1 per the W3C's documented failure technique for those elements; a control drawn with icon fonts, SVG, or CSS that lacks a name is filed here. One finding, one criterion.
2.5.3 Label in Name. 4.1.2 asks whether a name exists and is exposed; 2.5.3 asks whether the programmatic name contains the visible label text. A button labelled "Send" but named "submit-btn-primary" has a name, so it passes 4.1.2 and fails 2.5.3.
1.3.1 Info and Relationships. Structural semantics (headings, lists, table relationships, which label belongs to which field) are 1.3.1 territory. 4.1.2 is about the interactive components themselves.
4.1.3 Status Messages. Dynamic announcements that are not tied to a focused control (toasts, "3 results found", async save confirmations) are graded there. 4.1.2's change notification covers the state of the component the user is operating.
2.1.1 Keyboard. Custom controls usually fail both together, but they are separate findings: one is "assistive technology cannot understand it", the other is "the keyboard cannot operate it".

How AUDITSU tests this

AUDITSU's audit walkthrough runs a screen reader pass per screen: for each interactive control, the auditor records whether the name, role, and state are spoken correctly, and whether operating the control announces the change. The announcement formula is the test: what is it called, what is it, what state is it in. Each control gets a pass, fail, or not applicable result with evidence attached, so a silent custom toggle lands in the report tied to the exact screen and component.

One scoping nuance for non-web audits: on systems closed to assistive technology, where no screen reader can be installed or attached, the requirement is not applicable, because there is no assistive technology to consume the programmatic information. AUDITSU's walkthrough lets you record that determination explicitly rather than skipping the question.

For the full guided workflow, see the audit platform.