Toggle and ToggleSmall aria-label is better placed on the checkbox, not the label element

[FrivalszkyP]

Toggle and ToggleSmall aria-labels are misplaced - the attribute should go on the input element, not the label

Environment

MacOS

Chrome

VoiceOver

Detailed description

VoiceOver on Chrome does not announce the aria-label of the Toggle element because the attribute is on the label element, not the input itself.

What did you expect to happen?

I expected the text of the aria-label to be announced by VoiceOver upon focusing on the toggle element.

What happened instead?

The text was not announced, only the "tick box" and its on/off state.

What WCAG 2.1 checkpoint does the issue violate?

Looking at the "accessible name computation" specification, it seems to me that the current setup, having an aria-label on a label, is not in the specification. The aria-label attribute would be better suited on the input element itself.

Steps to reproduce the issue

1. Turn on VoiceOver for Chrome
2. Go to Storybook
3. Navigate to the Toggle element

Additional information

• It's important to note that the label is announced in Safari, which is probably the most used browser with VoiceOver
• I was unable to test this with NVDA/JAWS at the moment
• But as per specification, I thing the aria attribute should go onto the input element anyways.
• I tested it by moving the attribute using the Developer Tools, and it worked both with Safari and Chrome

Let me know if you found my reasoning solid, and I'll go ahead and create a PR!

[emyarod]

I am able to get VO to read out the aria-label on toggles at least in the storybook example, but I will await the feedback from our a11y experts about moving the label attribute to the input!

[tw15egan]

@dakahn any thoughts on this one?

[dakahn]

We build for VoiceOver used in Safari as, like you pointed out, that is the ideal and most used browser pairing generally

aria-label is unneeded. The toggle input is explicitly labeled by being wrapped in a label element. I've opened a PR to update the docs and demonstrate proper use of this component with a visual label at this link

That said, this component has problems. First and foremost WCAG Success Criterion 3.3.2 requires that form inputs have accessible labeling for both sighted users and users of assistive technologies. For a deeper dive see the section Intent in this Labeling and Instructions guide,

Currently we allow users to hide the label (perhaps to set it themselves and hopefully not to "save space"). But with JAWS 2020 and an aria-label attribute set on the label parent element -- no label is read 😢.

I think the label element should become a sibling to the <Toggle> instead of a parent like it currently is with it's id set as an aria-labelledby attribute on the input.

If users don't want our visual label on the element directly we should just drop <label> altogether and allow them to set their own label via aria-labelledby on the input itself.

[tw15egan]

Does not to be an issue anymore when testing in VoiceOver in Chrome in the V11 storybook 👍🏻