In one paragraph
ARIA toggle fields must have an accessible name means a tested custom choice or toggle does not identify the setting or option it controls. Supply meaningful text or a correct naming relationship, and keep state separate from the label. Prefer native controls where suitable. A role and name do not implement selection, mutual exclusion, keyboard behaviour, or a reliable form value.
Why it matters
Switch on does not tell a user whether sound, tracking, or email alerts are enabled. Colour-only product options are similarly ambiguous without useful variant names. A name should identify the setting or choice, with its state communicating whether it is active.
For a switch, the label generally stays stable as the on/off state changes. Changing the subject from Enable alerts to Disable alerts while also announcing state can create confusing or redundant output. Select the intended control pattern rather than combining toggle-button and switch conventions without a plan.
A native label association does not automatically name an arbitrary div given an ARIA role. Use the host element's actual capabilities and an appropriate author naming mechanism. Do not make absolute claims that exclude all form-associated custom-element designs.
How WebAuditOS evaluates this finding
The supplied aria-toggle-field-name rule covers its applicable custom checkbox, switch, radio, option, menuitemcheckbox, and menuitemradio roles. It accepts exposed text and supported ARIA or title naming paths, while native elements can be handled by other rules.
Serious impact maps to high severity. Names such as Option can pass without useful meaning. Closed popups or later-created options can be absent from the sampled state. The rule does not verify true state, grouping, mutual exclusion, or submitted values.
How to fix it
- Identify what the control asks and whether it represents an independent Boolean setting, a mutually exclusive choice, a selectable option, or another widget. Choose the appropriate pattern before adding labels.
- For a straightforward checkbox, a native example is:
<label><input type="checkbox" name="emailAlerts"> Email alerts</label>Keep server and application state aligned. This native alternative is handled by its applicable form-label rules rather than proving custom-role conformance.
- For a justified custom switch or choice, connect visible label text through the appropriate mechanism. Inspect its computed accessible name after rendering and avoid relying solely on visual proximity.
- Keep label and state distinct. A true switch needs the correct supported checked state, while a radio group needs consistent grouping and selection behaviour. Do not use mixed on a role that does not support that state.
- Name colour or size options with the actual variant wording used elsewhere in the purchase flow. Add appropriate visible text or another non-colour indication so the choice is not meaningful only to speech users.
- Implement the required keyboard and focus behaviour, including group navigation where applicable. A CSS animation that moves a thumb does not update semantics or persistence automatically.
- Test initial, changed, disabled, validation, and saved states. Verify that visible appearance, accessibility properties, and the value actually submitted or stored all agree.
- Rescan in the relevant open or populated state and manually assess the choice labels. A clean snapshot of a closed custom dropdown cannot validate every hidden option.
What the fix can break
A state-dependent label can change voice targets or make users uncertain whether the text describes the present setting or a future action. Follow a coherent pattern and keep wording stable where that pattern expects it.
Replacing a native control can lose form submission or keyboard behaviour. Preserve those capabilities rather than choosing a div just for easier styling.
Do not fill every unnamed swatch with an arbitrary numeric label. It should communicate the product option users will recognise when reviewing their selection.
Questions
Is on or off the setting name?
No. State alone does not explain the setting. Provide a meaningful subject as well.
Can a label for name any div switch?
Not automatically. Ordinary divs do not become natively labelable merely by receiving a role.
Does the rule check radio-group behaviour?
It checks name presence for applicable roles, not complete grouping and interaction correctness.
Which related checks help?
Review form labels, ARIA fields, and required properties.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared serious in axe-core 4.13.0, so every failure arrives as high.