Don't Be Lazy, Use HTML Labels Correctly(blog.goodsense.io)
blog.goodsense.io
Don't Be Lazy, Use HTML Labels Correctly
http://blog.goodsense.io/2012/12/07/dont-be-lazy-use-html-labels-correctly/
16 comments
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.
also why does the tooltip say the same thing as the link itself?
http://i.imgur.com/fdkpt.png
http://i.imgur.com/fdkpt.png
They have an ad banner almost as big as the login box, why would they be bothered with usability of that checkbox?
I just went over there and clicked it and all that happened was the box checked/unchecked :(
Maybe it's because I didn't fill in any other boxes?
The thing I hate is the warning that tells me that I'm about to view pages over a secure connection
Maybe it's because I didn't fill in any other boxes?
The thing I hate is the warning that tells me that I'm about to view pages over a secure connection
That is coming from the browser and is a good thing.
But it confuses/scares the average user, which is a bad thing. Just have your site be SSL all the time and users won't get this warning.
> But it confuses/scares the average user,
Rightly so, because it "is a bad thing" and websites shouldn't be putting users in that position.
Rightly so, because it "is a bad thing" and websites shouldn't be putting users in that position.
Sorry. I agree with you. I am personally pushing (don't have much influence but I can try) for 100% SSL all the time at my place as well.
Beat me to it. I always click on that label expecting it to tick the box. Why must people avoid convention?
Agreed. If you're going to give an unexpected user experience, it better be a damn good one.
<label><input type="checkbox"/>Stuff</label>
is easier.
is easier.
Not only is it easier and doesn't require the use of an ID, it also allows you to click in the space between the checkbox and the label text.
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.
You can combine nesting with for="id" to make sure you get complete compatibility.
I'm not sure about more recent versions of Safari, but I know this used to be the only way to get safari react to clicks on the label text.
I always remembered this as being "invalid" HTML, but a quick Google search turns up nothing. Can anybody shed some light?
Are you thinking Improperly nesting elements?
<i>Some <b>text</i> here</b>
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.
See nowarninglabel's comment below [1]; this doesn't carry the same benefits to accessibility as the ID-linking method.
[1] https://news.ycombinator.com/item?id=4890833
[1] https://news.ycombinator.com/item?id=4890833
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.
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.
Then these users should upgrade their software.
[deleted]
You don't have to link the label to the form element via ID. It's simpler to nest the element within the label.
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.
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 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.
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.
Wait... It's illegal to have a website that's not accessible? That's news to me.
http://news.cnet.com/2100-1023-962761.html
http://news.cnet.com/2100-1023-962761.html
This was an issue in the past, but it appears to have been fixed. See here for comprehensive test results:
http://www.html5accessibility.com/tests/form-labels.html
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.
http://www.html5accessibility.com/tests/form-labels.html
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.).
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.
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.
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).
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).
Just treat labels like remembering the closing tag of any html element.
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.
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.
The standard explicitly allows a <label> to contain a single input element, http://www.w3.org/TR/html-markup/label.html:
The label element may contain at most one descendant input element,
button element, select element, or textarea element.
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.
1. http://www.velocityreviews.com/forums/t155840-nesting-inside...
1. http://www.velocityreviews.com/forums/t155840-nesting-inside...
>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.
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.
Good point. You can do it that way too. I find it sometimes hard to use when you need to position the the radio button and the label text separately.
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 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.
Perhaps, but the other options to make it not anonymous don't allow label clicking either.
> 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.
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?
I am lazy. Django forms do it for me.
I've always used nested elements within a label tag, I've been advised to do so by people specifically concerned with HTML accessibility issues.
Especially important when you have mobile users filling out forms.
Let me try with embedded ruby:
<%= label_tag :is_premium, 'Toll free? (e.g. 1-888--*)' %> <%= check_box_tag :is_premium, true, params[:is_premium] %>
Am I doing it right?
<%= label_tag :is_premium, 'Toll free? (e.g. 1-888--*)' %> <%= check_box_tag :is_premium, true, params[:is_premium] %>
Am I doing it right?
I'd love to see a browser plugin that corrects this. There are so many sites that just don't bother.
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.
Unless you're a frontend developer, most people don't use labels. That and fieldsets. I still don't use those.
At Polyvore, we wrote our own centralized form generation library which always emits <label> with the correct behavior.
Another neat thing it does is optionally render dropdowns with fewer than 3 choices as radios -- 1 click to select vs 2.
Another neat thing it does is optionally render dropdowns with fewer than 3 choices as radios -- 1 click to select vs 2.
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.
They use labels (correctly) in almost all the forms on the site except this one.
They might have gone through the trouble to take it out on purpose.
[deleted]
This really bugs me. My bank's website doesn't use them correctly!