Accessibility Wiki

Custom interactive widgets must have an accessible name

Rule widget-name · Forms · impact critical · Static + live

↩ Back to the rules index · WCAG cross-reference

Why it matters

A native form field without a label fails critically — and a

without a name is exactly as broken: assistive technology announces "checkbox" with no clue what it controls. This covers the custom-widget twins of the native name rules (checkbox, radio, switch, slider, spinbutton, textbox, searchbox, combobox, listbox, and named-from-content items like option/tab/menuitem that ended up empty).

How to fix

Add aria-label, or aria-labelledby pointing at the visible label text. Named-from-content widgets (tab, option, menuitem) can simply contain their label as text.

Example

✕ Fails
<div role="checkbox" tabindex="0" aria-checked="false" class="icon"></div>
✓ Passes
<div role="checkbox" tabindex="0" aria-checked="false" aria-label="Subscribe to newsletter"></div>

Example

✕ Fails
<div role="combobox" tabindex="0" aria-expanded="false"></div>
✓ Passes
<div role="combobox" tabindex="0" aria-expanded="false" aria-label="Choose a country"></div>

WCAG success criteria

4.1.2 Name, Role, Value — Level A

Every UI component must expose a correct name, role, and (where relevant) state/value to assistive technology.

Understanding 4.1.2

Standards

This rule contributes to the following standards:

WCAG A EN 301 549

Standard Criteria
EN 301 549 9.4.1.2

References