> Both Dragon Naturally Speaking for Windows, and Voice Control for macOS and iOS, don’t recognize implicit association, so the [nesting input inside label without explicit for-id reference] wouldn’t work.
Naturally Speaking was reportedly acquired by a company named "Microsoft", and Voice Control have some connections to that "Apple" company.
[1] https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...
> Note that while using aria-labelledby is similar in this situation to using an HTML <label> element with the for attribute, there are some very important differences. The aria-labelledby attribute only defines the accessible name. It doesn't provide any of <label>'s other functionality, such as making clicking on the labeling element activate the input it is associated with. That has to be added back in with JavaScript.
The best compromise would be to both wrap the input inside the label _and_ use the “for” attribute.
Typically, it’s best to use elements and controls that are already accessible, as ARIA is more intended to give additional accessibility to components that might not be traditionally accessible, or that require more robust accessibility control.
Since I do mostly asp.net mvc, I created a bunch of "Accessible" extension methods off the HtmlHelper object.
<%: Html.AccessibleCheckbox("MyCheckbox", label: "My Checkbox") %>
This would output something like: <label><input type="checkbox" name="MyCheckbox" aria-label="My Checkbox" /> My Checkbox</label>
This is a bad example since the primary reason for not giving IDs is because it is a dynamically created checkbox inside a loop or some other partial view that you might not know if it is a unique ID for the page or not.But not for keeping the input outside of the label.
I've brought up it here just because parent comment stated what perhaps majority of developers believe:
> [nesting] completely avoids [possible gaps in the UI areas] and you don't need to come up with a unique id to use with 'for'.
As for separated elements here, I can imagine scenarios when we need them too (for example if you need to shuffle them in some way, or intend to use a pseudo element of the label), but as noted, it is rarely best solution and requires way more scrutiny and complexity.
This is not a problem for radio buttons, but I suspect a few people have been bitten by this and do it "just to make sure". In the same way, adding a semi-colon at the end of a line of JavaScript is rarely useful but people put them everywhere because they don't know when it's needed exactly (granted that one is a bit tricker to remember).
Put the label around the input, then put a span for the text if you want some styling for the text. You can even make the label display:flex and handle the positioning of the text that way.