Back in the day I used to think this was taboo for some reason, but maybe it was only for XHTML to enforce one-to-one label -> input association. Flexbox seemed a bit redundant, since even with the non-nested syntax I'd think it would lay out inline and you can just add some padding in the same way.

The alignment is not exactly the same when you just put them side by side. Flex can center the radio with the text a bit nicer. Otherwise it sits above the text baseline I believe.

This was my first thought. The entire text label should toggle the radio or checkbox, not just the box and the padding.

Bootstrap moved from <label><input></label> in 4.0 to <input> + <label> in 5.0 for radios/checkboxes [1]. I was curious about why but my guess is that it adds some simplicity for theming when repositioning/padding either the label or input.

[1] https://getbootstrap.com/docs/5.3/forms/checks-radios/

They more than likely made that decision to be able to style the label based on input state using the + sibling selector. I use that trick for literally every visible input now.

I think it's for material design inspired focus animations. :has selector wasn't a thing, so you have to use + sibling selector to target the label of a focused input

    input:focus + label {} 
    label:has(input:focus) {}

Incidentally Bootstrap 5.3 seems to have the same problem as the article describes. There is a gap which doesn't do anything if clicked, right between the radio button and the label.

Even with nesting you still need for/id attributes to make it accessible to common voice command software: https://www.tpgi.com/should-form-labels-be-wrapped-or-separa...

That’s the voice control software’s problem.

At the end of the day it’s your users’ problem. Ideally their assistive tech would work, but if it doesn’t and you’ve got an easy fix then you should implement that fix.

I disagree. Of course you could fix that. But that would mean that you can fix a thousand and one issues that's caused by other softwares erroneous content handling. Which leads to nothing but bloat and introduces just more code that could come with more bugs.

If your software works and is designed as intended, then sometimes it stays the users problem. Unfortunate, but otherwise problems will stay forever.

Your software isn’t working, because the user cannot use it. Your UI is always a combination of whatever hardware and software come together to give an experience. Everyone chooses to marginalise certain segments of users’ technologies – I don’t support IE any more of course – but I typically won’t drop support for technologies that are vital assistive technologies for that segment of users.

(If you need a personal story to bring it home, the only way my dad, a programmer in the 70s-90s, could continue to use computers when he suffered from MND / ALS, was to use voice control software.)

You’re basically enabling for these shitty variants of voice control software to exist. Html, css and js allow dor more granularity in how ui works, but using them this way is just absurd.

shrug They exist regardless, and the users have no real other options. I’ve found in my career that devs tend to fall into the “caring about the effect” and “caring about the artefact” buckets, and I guess you’re in the second category? There’s no one right place to be – without people in the second we‘d have less effective solutions overall – but I hope your team is also balanced by people in the first.

And unless you're google or facebook, people will not change their voice control software for your website.

Not sure I agree with the conclusion of that article, according to it, only 2 screen readers don't support nested labels, I couldn't find statistics on how prevalent these are, but there are a lot of alternative screen readers one could use which might support nested labels since they're not mentioned there (I've mainly heard of JAWS, which isn't mentioned there), so it doesn't seem to be an inherent limitation of assistive technology, just a bug in some (popular?) screen readers.

VoiceControl and Naturally Speaking aren’t screen readers: they’re voice command software. They’re designed for people with mobility problems, not vision problems. There’s no inherent limitation here that couldn’t be solved by bug fixes, but they’re the two major pieces of assistive tech in that sector so can’t be dismissed without dismissing people who need that functionality.

Fair enough, so to test things out I've enabled Voice Control and tried whether it makes a difference how the elements were arranged:

At least with Chrome, it does not make a difference! It correctly determined the label and I could just tell it to click on that particular checkbox.

Since Dragon Naturally Speaking doesn't seem to have a trial, as well as having a broken shop page you can't order from, I can't give it a test, but that articles advice seems rather questionable to me.

That feels somehow like building your website for IE6 because some people still use them.

The article is right. A nested input with a for attribute is always better than an input without one.

Maybe not for the screenreaders of today, but maybe for the screenreaders of tomorrow.

I think that would not have worked with the grid CSS approach.

I guess it is kinda beside the point though as it was just an example to illustrate the point.

Just a note that in a framework like react, this will introduce an error that propagates when people attempt to use something like “google translate” on your site. You’d need to wrap the “Foo” in an element to mitigate.