However, wouldn't putting the input inside of the label (before the label text) be a better solution than fiddling too much with CSS and flexbox? It's more foolproof to ensure clicks within the label activate the input, and eliminates the need for the "for" reference.
The one potential downside to doing it the way you describe is (assuming the same CSS flexbox layout) now all the white space on the right side of the label acts the same as clicking the radio/checkbox. Which is almost like the opposite problem to the original issue.
This might actually be a good thing for some designs/contexts, but not always. For example, on mobile it might lead to miss-clicks while trying to scroll past the <label>s
> on mobile it might lead to miss-clicks while trying to scroll past the <label>s
You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.
> You can scroll on mobile by swiping over the text of a label itself without activating the input; this isn't generally a concern.
Generally speaking yes, but there’s still a chance of triggering it by touching the whitespace by mistake. Whereas if it wasn’t the full width it just wouldn’t be possible to begin with.
I don't know how bad that is in practice: https://a11ysupport.io/tests/html_label_element_implicit
...but it does look worse than explicit: https://a11ysupport.io/tests/html_label_element_explicit
> Whenever possible, use the label element to associate text with form elements explicitly
> [..]
> In some situations, form controls cannot be labeled explicitly... Generally, explicit labels are better supported by assistive technology
...but people have been saying that for like 15 years now, I don't know how big of a deal those failures are. That'd be a good blog post
If some company makes a shoddy half baked solution for sale (looking at you, Dragon), and they don’t understand basic HTML that has been standardized for years, that’s not my problem. The same way I don’t only use the subset of web technologies that the AOL Premium web browser supports for $10 bucks a month.
I think the implication is these voice control programs aren't using the accessibility tree built by the browser but parsing the DOM themselves, poorly. It's not really surprising for Dragon since it does hardly anything in a browser without its browser extension installed and extensions don't have access to the accessibility tree. It's more surprising for macOS Voice Control.
[1] https://www.freedomscientific.com/products/software/jaws/
[2] https://webaim.org/blog/jaws-license-not-developer-friendly/