ARIA Toggle Fields Must Have an Accessible Name: How to Fix It

This check flags toggle controls — anything with role="switch", role="checkbox", role="radio", or role="menuitemcheckbox" — that carry no accessible name. A screen-reader user hears “switch, on” with no clue what it switches, so the whole control becomes a coin flip they can see the state of but not the purpose.

A state with no subject is useless

Toggle fields communicate two things: an identity (“Email notifications”) and a state (on/off, checked/unchecked). Native inputs get the identity from a wired-up <label>. Custom toggles built on <div> or <span> with an ARIA role have no such wiring — unless you supply a name explicitly, assistive tech announces the state into a void. “On” on. What’s on? Nobody hears.

A real failing pattern and the fix

<!-- FAILING: a switch with visible text nearby but no linked name -->
<span>Dark mode</span>
<div role="switch" aria-checked="false" tabindex="0"></div>

<!-- FAILING: custom checkbox, no name at all -->
<div role="checkbox" aria-checked="true" tabindex="0"></div>

<!-- FIXED with aria-labelledby pointing at the visible text -->
<span id="dm-label">Dark mode</span>
<div role="switch" aria-checked="false" tabindex="0"
     aria-labelledby="dm-label"></div>

<!-- Or, simplest of all, use the native control -->
<label>
  <input type="checkbox" checked> Remember this device
</label>

The native <input type="checkbox"> inside a <label> is bulletproof: it’s focusable, toggleable with Space, and named by the label text, with zero ARIA. Reach for the custom role="switch" only when a designer demands a sliding toggle a checkbox can’t give you — and then you owe it a name.

Four ways to name a toggle, ranked

Prefer aria-labelledby over aria-label whenever visible text exists — it keeps the spoken name and the on-screen words in sync, which also satisfies the label-in-name requirement.

How to detect it on your own site

1. axe DevTools: run a scan and look for “aria-toggle-field-name” (and the related “aria-required-attr” if aria-checked is also missing). It pinpoints every switch, checkbox, or radio with no computable name.
2. Lighthouse: the Accessibility audit reports “ARIA toggle fields do not have accessible names” and lists the failing elements.
3. WAVE: run the extension; custom toggles with no label surface as a “missing form label” or empty-button flag depending on markup. Cross-check by inspecting the ARIA role in the Details panel.
4. Screen-reader pass: tab to each toggle with VoiceOver or NVDA on. If you hear a state (“on”/“checked”) with no preceding label, that’s the failure in the wild.

How to fix it

1. Default to a native <input type="checkbox"> or <input type="radio"> inside a <label>. Style the label to look like a slider if design demands it — the semantics stay clean.
2. If you must keep a custom role="switch", point aria-labelledby at the id of the visible text element.
3. For an icon-only toggle with no visible words, add a concise aria-label describing what it controls, not its state (“Mute audio,” not “On”).
4. Make sure the toggle is focusable (tabindex="0") and updates aria-checked on activation — a named switch that never changes state is only half fixed.
5. Re-scan; aria-toggle-field-name should report zero.

Why unnamed toggles hurt real users

Settings screens are wall-to-wall toggles — notifications, privacy, autoplay, two-factor. A blind user arrives to flip one specific switch and instead meets a row of anonymous “on/off” states with no labels, unable to tell which controls what. They either guess and risk turning off something important, or abandon the task. That’s the exact spot where an inaccessible toggle turns into a support ticket or a lost signup. Get the naming right and the control becomes trivially usable. The sibling requirement here is choosing a role that actually fits the element in the first place — see ARIA role must match the element.

FAQ

Isn’t putting visible text next to the switch enough?

No. Visual proximity means nothing to the accessibility tree. Unless you link that text with aria-labelledby (or use a wired <label>), the toggle has no programmatic name even though sighted users see the words.

Should I use role="switch" or role="checkbox"?

Use switch for an on/off setting that takes effect immediately (like a light switch), and checkbox for an option you tick as part of a form you’ll submit. Both need an accessible name regardless.

Can I just add title to the div?

title can supply a name as a last resort, but it’s unreliable on touch, invisible until hover, and low in the naming order. Prefer aria-labelledby or aria-label.

Do radio buttons in a group each need a name?

Yes — each role="radio" needs its own accessible name (the option), and the surrounding role="radiogroup" needs a group name (the question). Naming the group but not the options, or vice versa, still fails.

What about the state — is aria-checked required too?

For a toggle, yes. A name without aria-checked tells users what the control is but not whether it’s on. This check targets the missing name specifically, but ship both together. Naming widgets like tooltips follows the same discipline.

My toggle is built with a hidden checkbox and a styled label — am I safe?

Usually yes, and it’s a solid pattern. The trick is to hide the real <input> visually (off-screen or clipped) rather than with display:none, because display:none removes it from the accessibility tree along with its label. Keep the input in the tree, wire the label to it, and let CSS paint the slider on top. Screen readers then get a genuine, named, stateful checkbox while sighted users see your custom design — the best of both, no ARIA required.