Skip to content
A11ySignal
Level AWCAG 2.0WCAG 2.1WCAG 2.2EN 301 549 § 9.4.1.2

4.1.2
Name, Role, Value

Every control must expose what it is, what it is called, and what state it is in.

What the standard says

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.

Why it matters

This is the criterion custom components break. A `div` styled as a checkbox tells assistive tech nothing about being checked.

What a failure looks like

  • failsA `<div>` toggle with no `role="switch"` and no `aria-checked`.
  • failsAn icon button with no accessible name.
  • failsAn accordion whose header never updates `aria-expanded`.
  • failsA custom `<select>` with no `role="combobox"` and no `aria-activedescendant`.

How to fix it

  • doUse the native element wherever one exists. `<button>`, `<input type="checkbox">` and `<select>` get all of this for free.
  • doFor a genuinely custom widget, follow the ARIA Authoring Practices pattern for it, including keyboard behaviour.
  • doKeep state attributes in sync with what is on screen.

How A11ySignal checks it

29 automated checks run against this criterion on every scan.

Also under 4.1 Compatible