You may argue that it's simpler (I'd argue it's not), but either way nesting elements inside labels usually breaks assistive technology: http://www.w3.org/TR/WCAG20-TECHS/F68.html
That's a good reason to use the format the author suggested instead of nesting.
This is why I hate the Web Content Accessibility Guidelines:
> In the following code examples, the names associated with the text input controls are not properly determined by assistive technology.
Which assistive technology? Why doesn't the assistive technology simply implement HTML properly? Associating a label with an element by nesting has been standardized since HTML 4.01 at least (I haven't bothered to check further back), and I'm pretty sure all of the browsers implement it properly.
Now, instead of simply writing a bunch of guidelines that say vaguely "not properly determined by assistive technology", they could show the results of testing, in a format similar to http://caniuse.com/. That would actually be useful; you could determine if the problem still exists or not, based on how many people are using some old buggy version of assistive technology.
But, rather, the WCAG are simply a bunch of prescriptive rules with vague justifications, and then various people on standards list try to argue that because there are laws that have been written that specify that certain things must comply with accessibility standards, these kinds of guidelines have the force of law and thus trump all other interests in standardization.
In the United States accessibility can not be ignored because the enables only a small portion of the public (see: The Americans with Disabilities Act). I agree that the guidelines could do a better job of explaining which technologies to support so as to enable accessibility. But I worry that some people would be led to think that disabled populations, who are in a minority, can be ignored if the site owner desires. This is rightly illegal.
It is not illegal to have a website that's not accessible. It's illegal for the government to use or mandate software that's not accessible; and thus anyone who wants to sell to the government must make their software comply. But of course, in many cases this means that people either find some exemption or workaround, or do a cursory and not very useful job of making it accessible.
I am not arguing that you should ignore accessibility, or that it's not a good thing. What I'm saying is that there's a certain group of people in web standards who put accessibility over everything else, and refuse to adopt newer, better technologies for providing accessibility because some older, broken technology was already standardized on years ago.
For instance, there's the whole fight over longdesc in HTML5. longdesc has been standardized for a while, and lots of accessibility standards require or recommend it. It's supposed to contain a link to a page containing a textual description of the image; it is intended for cases in which you can't fit a full description into the "alt" attribute. But so many authors use it incorrectly; some just put the long description right in the longdesc attribute, some had broken links, and so on, that most screen reader users either ignored it or didn't even know it existed in the first place. One reason it's so badly broken is that normal user agents don't provide any way to access a longdesc attribute, so you never see that it's broken unless you try to use a screenreader and specifically test the longdesc.
So the HTML5 authors decided to deprecate longdesc in favor of newer solutions that were more likely to provide working description, like aria-describedby, which refers to another element on the page. That element is much more likely to work as it's already there on the page, visible to people using ordinary visual user agents, unless it's explicitly hidden. If you still want to provide a link to another page, you can just point aria-describedby at a link.
But many of the accessibility crowd complained loudly at deprecating the severely broken longdesc attribute, merely because it had already been included in so many accessibility guidelines like this, not because it was actually technically the best solution.
Note that according to this document the use of ARIA, the new hotness in accessibility, actually confuses some combinations of accessibility tool and browser. Should we not use that?
I have to say, as someone with an interest in accessability, the tendency for the accesability "scene" to opt for changing the behaviour of millions of web devs by writing obscure documents that the vast majority of HTML coders will never be aware of, much less read, with fewer still understanding or following the complicated advice within, rather than working on fixing the handful of relevant software is baffling to me.
Maybe it's a holdover from when a stagnant IE6 ruled over the internet with no changes in sight. Now I'd rather see them apply market pressure by recommending anyone with accessability issues uses a browser/OS/accessability tool that actually works and put their effort into the various viable open source efforts.
Why can't assistive technology figure out what a label with a single nested control refers to? The browsers seem to do it just fine.
Once a website reaches a certain scale (especially with rich web apps), global DOM id's become an almost impossible headache to deal with (because of multiple views which duplicate id's, coordination of global names across hundreds of files, etc.).
Global id's are basically an antipattern, whereas labels with nested controls have always seemed pretty workable.
>Once a website reaches a certain scale (especially with rich web apps), global DOM id's become an almost impossible headache to deal with (because of multiple views which duplicate id's, coordination of global names across hundreds of files, etc.).
The most effective way I've found to deal with them in those circumstances is to have them generated automatically at runtime when they are absolutely required. It's still a terribly backwards way of doing things, but at least you can ensure their uniqueness that way.
Once a website reaches a certain scale you better have a backend that generates your forms already.
Since input elements already have unique names/values, otherwise the backend wouldn't know what you've posted. You can use a (scrambled) version of this, plus a sequence number if required in case of multiple inputs with same name.
Remembering to manually insert the label for every radio input is just bound to fail.
On a large-scale rich webapp, input elements don't have to have unique names, because you're not posting forms directly to the backend.
Instead, you identify your input elements with classes, use something like jQuery to read the values from elements with certain classes from inside a specific DOM element only (not globally), and then POST to the server using AJAX. Nowadays, user interface elements have no need to be tightly coupled with HTTP parameters.
ID's worked in the era of non-JavaScript. But for large dynamic sites where JavaScript is required (webapps, etc.), I haven't used ID's anywhere for years, thank God (like I said, an antipattern).
You could probably write a library that did smart renaming of id's.
For example, <label id="R_../../checkbox1+_label"> would be renamed to the id of the first checkbox on the parent's parent with _label appended to it. The library could be smart enough to only recognize the R_ prefix as needing to be renamed.
Not saying that you should do that, just that you could.
It's not invalid, it's a limitation of current assistive technology and how people use it. Eventually, AT will all be in line with standards, but until then, when agnostic about the choice, there's a good reason to go with one format over the other, considering that both formats are valid.
Usually? Which ATs are you describing? We care about this sort of thing and weren't aware of that constraint - a quick Google doesn't highlight any obvious issues with Jaws or NVDA, except for this [1] in 2003. But since then there have been huge changes in assistive tech - pretty sure the whole ARIA thing didn't exist back then, and there's probably more choice in ATs now than ever before.
>You may argue that it's simpler (I'd argue it's not)
I would argue that when you're creating dynamic content, dealing with IDs is inelegant. If I already have a reference to a DOM node, I shouldn't have to assign it a unique ID just so I can tell another node about it.
That's a good reason to use the format the author suggested instead of nesting.