Whatever you do, don't make clicking the label do something other than check/uncheck the box, like how Xfinity's boneheaded login page brings up a 'help' screen when you click on 'Keep me signed in': https://login.comcast.net/login
Also, when that help screen appears, everything else on the page darkens out except the CAPTCHA (presumably because it's done in flash). It probably leaves some users confused about what the dancing text has to do with the help page, and what they are supposed to do with it in that context.
Came here to post this. This is very important and as a bonus, if you add some padding to the label the click area around the actual radio button becomes a bit larger.
You can combine nesting with for="id" to make sure you get complete compatibility.
It's not invalid; it's one of the two ways of using a label element. However, IE 6 didn't support it which is why I always resorted to the ID variant. The difference in typing isn't that large anyway.
Why isn't the burden placed on assistive technology to operate properly? There is this habit in web development of being enablers for users with dated clients that's holding back progress. I know it sounds cold in this context, but it's the truth.
There's also a habit in web development of not testing with assistive technologies. I'm certainly personally guilty. Of course, few people test their site's appearance through colorblindness simulators and other things that reproduce how a non-trivial percent of their viewers see the site (yet still bitch and moan about the 2% or so using IE6/7; some 8% of males have a form of colorblindness according to Wikipedia)
Part of the problem is that when assistive technology breaks, it's user is completely SOL. Another is that replacing it is often expensive (both financially and operationally). This makes it a lot harder than simply upgrading to the latest version of $browser.
edit: a comment below suggests that both of our comments are based on wrong info, and that screen readers and such actually prefer nested labels over id/for attributes. I don't have evidence either way, but I think both developers of websites and of AT are doing the handicapped a disservice as fellow humans.
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.
Perhaps LinkedIn is doing this on purpose? It seems like this is a feature they would not like to see used very much, and by A/B-testing they discovered that people use anonymous posting way less when confronted with such a non-standard checkbox label behavior.
I think "normal" checkbox label behavior is very much ingrained in the web development community, thats why I suppose the developers at LinkedIn know about it as well.
> I’m surprised that LinkedIn doesn’t use labels correctly.
I'm really not. My experience with LinkedIn in terms of production quality code has been quite bad - not being able to unsubscribe from emails because of bugs that crash the website among the most annoying one.
My guess is that this isn't because of lazyness but because of getting users NOT to check something. I often find that opt-outs of social sharing, sending statistics or something else that the application will benefit from isn't linked to the label. Maybe because they want to make it harder to check/uncheck?
This is the first time I've heard of labels. A lot of us learned html from googling and ending up on w3schools, which is not the best reference. http://w3fools.com/ has a good list of the erroneous info.
That's impressive. Dealing with forms is harder than most people think. Ever try positioning or styling input fields? It's not trivial like other html elements. That's why wufoo is popular and bootstrap puts so much effort on forms.
