Annex

WCAG 4.1.2 — Name, Role, Value

Every interactive element must expose a name (what it is), a role (what it does) and its state (expanded, selected) to assistive technology.

What this means for a store

On a store this shows up in the cart, search and filter components. An Add to Cart control built from a div with a click handler cannot be focused with a keyboard and does not announce itself as a button — the customer simply cannot add the product. That is a lost sale, not a degraded experience.

The failures we see most often

A div or span with an onclick handler used instead of a button.

Why it happens: Resetting the browser's default button styling feels like work, so a div is styled instead. Role, focusability and keyboard support are all lost with it.

Accordions, tabs and filter panels that never update aria-expanded.

Why it happens: The chevron rotates visually, but the state lives only in a CSS class and never reaches the accessibility tree.

Custom select and dropdown components written without the matching ARIA pattern or keyboard behaviour.

Why it happens: A native select is replaced with a scripted component for styling reasons and the ARIA work is skipped.

The same id used on more than one element, so aria-labelledby and label/for resolve to the wrong node.

Why it happens: A repeating template prints a fixed id for every item in a list.

How to check it yourself

  1. Put the mouse aside and try to add a product to the cart using only Tab and Enter or Space.
  2. Open and close an accordion and watch aria-expanded change in the browser's accessibility inspector.
  3. Check the page for duplicate ids.

Fixing it, by platform

What this page covers

What follows is the practical meaning of a WCAG 2.2 success criterion. Automated tests catch only a portion of accessibility issues, so a clean scan result does not mean compliance. Platform paths vary by version and theme.

Source

The formal definition of this criterion: W3C — Understanding Name, Role, Value