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 <div role="checkbox"> 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#

<div role="checkbox" tabindex="0" aria-checked="false" class="icon"></div>

<div role="checkbox" tabindex="0" aria-checked="false" aria-label="Subscribe to newsletter"></div>

Example#

<div role="combobox" tabindex="0" aria-expanded="false"></div>

<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

References#

• WCAG — Name, Role, Value