Skip to content
Pandus
en Change language
Menu

WCAG 4.1.2 Name, Role, Value

Updated October 14, 2026 · 3 min read

Level
A · WCAG 2.0
EN 301 549
9.4.1.2
What the checker tests
Partly automated: Clickable areas of an image have no description, Accessibility attributes are used on the wrong elements, Some elements have a braille label but no normal name, Custom buttons have no name, Accessibility attributes are used in the wrong situation, Some elements use outdated accessibility roles, The whole page is hidden from screen readers, Hidden elements can still be reached with the keyboard, Custom input fields have no label, Some labels are placed where screen readers ignore them, Custom controls are missing required information, Some elements use a role that does not exist, Some switches and checkboxes have no name, Some tooltips are empty, Accessibility attributes are misspelt, Accessibility attributes have wrong values, Some buttons have no name, Some labels point to the wrong element, Embedded content has no name, Several embedded frames have the same name, Some form buttons have no name, An image button has no text description, Form fields have no label, Some links do not say where they go, Clickable elements are nested inside each other, A dropdown has no label, Some expandable sections have no name
Official text
Understanding 4.1.2 Name, Role, Value (W3C, in English)

Success criterion 4.1.2 makes sure that screen readers, voice control and other assistive technologies can understand and operate every control on a page. A screen reader user hears "button, Add to cart"; a voice control user says "click Add to cart". If a control has no name, the wrong role or a state that never updates, these users cannot shop. It is level A and appears in EN 301 549 as clause 9.4.1.2.

What the criterion requires

For all user interface components — form elements, links and components generated by scripts, among others:

  • the name and role can be programmatically determined;
  • states, properties and values that the user can set can be programmatically set;
  • notification of changes to these items is available to user agents, including assistive technologies.

W3C notes that the criterion is mainly for authors who build or script their own components. Standard HTML controls used according to the specification already meet it. Custom widgets — menus, tabs, accordions, sliders, custom selects — need roles and states supplied with ARIA, and those states must change as the widget changes.

Typical failures on an online shop

  • icon-only buttons (cart, search, close, wishlist heart) with no text and no aria-label;
  • product image links with an image that has no alt text, so the link has no name;
  • a size or colour picker made of div elements with click handlers and no role or selected state;
  • a mobile menu button whose aria-expanded stays "false" when the menu is open;
  • form fields with no label, or a select without a name;
  • elements hidden with aria-hidden="true" that still receive keyboard focus;
  • iframes for video, maps or payment with no title;
  • ARIA attributes that are misspelled, not allowed on the role, or have invalid values.

How to check it

Automated: our checker runs many rules for this criterion, among them button-name, link-name, label, select-name, input-button-name, frame-title, aria-hidden-focus, nested-interactive, aria-required-attr, aria-valid-attr-value and the other ARIA rules (see the rules list). It reports each failing element with its selector. It cannot judge whether a name is meaningful, or whether states update while the control is used.

By hand: use a screen reader (NVDA on Windows, VoiceOver on macOS or iOS) and move through the header, product page and checkout. For each control, listen for a sensible name, the right role and the current state. Open and close menus, accordions and variant pickers and check the state changes are announced.

How to fix it

  • Use native elements: <button> for actions, <a href> for links, <input>, <select> with <label>.
  • Give icon-only controls an accessible name, with visually hidden text or aria-label.
  • For custom widgets, follow the ARIA Authoring Practices pattern and update aria-expanded, aria-checked, aria-selected with the UI.
  • Never put focusable elements inside aria-hidden content; give every iframe a title.

Frequently asked questions

What does name, role, value mean?

Name is what a control is called ("Add to cart"), role is what kind of control it is (button, link, checkbox), and value or state is its current setting (checked, expanded, 3 items). Assistive technology needs all three.

Do standard HTML elements meet 4.1.2?

Yes, when used according to the specification. A real button, link, input or select with a label exposes name, role and value. The problems usually come from custom controls built from div and span elements.

Can an automated checker find 4.1.2 issues?

It finds many of them: buttons and links without a name, form fields without a label, invalid or missing ARIA attributes, hidden elements that can still get focus. It cannot tell whether a name is meaningful or whether states update correctly while you use the control.

Is adding ARIA always the fix?

No. A native HTML element is usually more robust than ARIA added to a div. Incorrect ARIA can make a control worse than no ARIA at all.