Skip to content
4.1.2 · Level A · WCAG 2.0 · Robust → Compatible

Name, Role, Value

Every UI component has a programmatically determinable name, role, and (where applicable) state/value, and changes to those are exposed to assistive technology.

Why it matters

This is the catch-all for custom widgets: a <div> styled as a checkbox with no role, no accessible name, and no checked state is invisible to a screen reader as anything other than an unlabelled clickable area.

Automatically detected

axe-core catches most missing-role and missing-name cases directly. Whether a custom widget's exposed state stays correctly in sync through user interaction is worth a manual or judgement-pass check.

Related axe-core rules: aria-required-attr, button-name, aria-valid-attr-value

Fails

<div class="checkbox" onclick="toggle(this)"></div>

No role, no accessible name, no aria-checked — a screen reader announces this as a generic, unlabelled, non-interactive element.

Passes

<div role="checkbox" tabindex="0" aria-checked="false" aria-label="Email me updates" onclick="toggle(this)"></div>

role, name, and state are all exposed — though a native <input type="checkbox"> is simpler and preferable wherever the design allows it.

Openwell finds violations like this one across your whole site, clusters them by the component that caused them, and generates a fix that's re-validated before you see it.

Scan your site free
WCAG 4.1.2 Name, Role, Value — what it requires and how to fix it — Openwell