Why Your Form Checkboxes Need to Have Label Tags(uxmovement.com)
uxmovement.com
Why Your Form Checkboxes Need to Have Label Tags
http://uxmovement.com/forms/why-your-form-checkboxes-need-to-have-label-tags/
38 comments
This is the single most annoying thing I find web devs doing on a regular basis. Please use labels, web devs. It applies not only to checkboxes but any type of input. It's a free, easy usability improvement. It even makes it easier to style the text with CSS since it's wrapped in a specific tag!
> It even makes it easier to style the text with CSS since it's wrapped in a specific tag!
Labels don't have to wrap inputs. In fact, mine almost never do, that's too much of a pain to align. They're usually linked to their input via @for (and at some point in the future, I'll be able to do that with inputs and forms via @form, what a glorious day that will be)
Labels don't have to wrap inputs. In fact, mine almost never do, that's too much of a pain to align. They're usually linked to their input via @for (and at some point in the future, I'll be able to do that with inputs and forms via @form, what a glorious day that will be)
Agreed, however I think the problem lies with most tutorials out there which don't follow this logic and newbie devs just follow this path without thinking about it.
I have used labels in the past for radio buttons and checkboxes, but had never considered them before for input-type elements. It's a brilliant idea, and so easy to implement too!
When I evaluate a portfolio attached to a resume this one of the first things I check for of there is a form in the portfolio. If the developer hasn't done it that is a big strike right there.
I was on a site the other day, I can't remember where but it was "Fortune 500" level stuff and they didn't have checkbox labels. It amazes me how much this gets missed.
I was on a site the other day, I can't remember where but it was "Fortune 500" level stuff and they didn't have checkbox labels. It amazes me how much this gets missed.
As "theoatmeal" says:
"Use a label tags with these; that way I don't have to be a goddamn marine scout sniper to sharpshoot the tiny little box. It's 2011 and 90% of the websites I use still haven't figured this out."
Nice little usability rant: http://theoatmeal.com/comics/shopping_cart
Nice little usability rant: http://theoatmeal.com/comics/shopping_cart
Irony is that, we are discussing use of label tag, on the website(news.yc) which also doesn't have it(label tag).
Example:
- Search Box Below
- http://news.ycombinator.com/submit
Example:
- Search Box Below
- http://news.ycombinator.com/submit
The real irony is that the comment submit form on the site where this was posted doesn't use a label tag. Hopefully he'll fix that or get in touch with me and let me help (I offered to help - apparently it's a WordPress plugin that doesn't have the label element).
I think there are bigger issues to fix on HN:
- Everything is a table - <FONT> everywhere - URLs on self-posts doesn't convert into a link - Un-upvote/downvote
- Everything is a table - <FONT> everywhere - URLs on self-posts doesn't convert into a link - Un-upvote/downvote
The post reminded me of a time where we had a form that exhibited odd behaviour. When selecting a check box by clicking the label - the page would change. It turned out that the id of the navigation link matched the check box that was referred from the label!
He used an image for some reason for the text, so I can't copy/paste the code and edit it.
But there is no need to always use id="xx" in the input and for="xx" in the label. The majority of the time you can just wrap the label tag around the input tag. It works great and is very fast to do.
i.e.:
But there is no need to always use id="xx" in the input and for="xx" in the label. The majority of the time you can just wrap the label tag around the input tag. It works great and is very fast to do.
i.e.:
<LABEL><INPUT type="checkbox" name="foo">Include bar?</LABEL>
<INPUT type="checkbox" name="foo" id="foo"><LABEL for="foo">Include bar?</LABEL>
> The majority of the time you can just wrap the label tag around the input tag. It works great and is very fast to do.
Actually the majority of the time you do not do that, as it's a pain in the ass to correctly style for alignment. Even more so in a cross-browser fashion. Splitting them provides far more stylistic flexibility, and is — I think — more correct semantically.
It also makes for much simpler scripting, as you just need to dereference @for when handling a proxied action from the label to the input, if you have mixed situations you need to handle both, and the first case requires a filtered traversal of the label's children.
(the piece had numerous other failings I find more problematic than this: no names on controls, crummy and non-informative ids, and the UX of the blog itself which you mentioned: code as a picture instead of as text)
Actually the majority of the time you do not do that, as it's a pain in the ass to correctly style for alignment. Even more so in a cross-browser fashion. Splitting them provides far more stylistic flexibility, and is — I think — more correct semantically.
It also makes for much simpler scripting, as you just need to dereference @for when handling a proxied action from the label to the input, if you have mixed situations you need to handle both, and the first case requires a filtered traversal of the label's children.
(the piece had numerous other failings I find more problematic than this: no names on controls, crummy and non-informative ids, and the UX of the blog itself which you mentioned: code as a picture instead of as text)
I've been doing this for years and have never had the slightest alignment issue. Example?
Or do you mean if the label and input are in different columns of a table - in that case, obviously split them. I'm talking when they are near each other.
And I totally disagree about the semantics. Wrapping the label is much more correct semantically - it says this input and these words are related.
I do not understand what you mean by "simpler scripting". Are you trying to make a special script action when they click the words? I wouldn't do that - make the action on the input element.
Or do you mean if the label and input are in different columns of a table - in that case, obviously split them. I'm talking when they are near each other.
And I totally disagree about the semantics. Wrapping the label is much more correct semantically - it says this input and these words are related.
I do not understand what you mean by "simpler scripting". Are you trying to make a special script action when they click the words? I wouldn't do that - make the action on the input element.
Per the spec, both approaches are correct.
http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1
I think using an explicit "for" attribute is cleaner than bundling the control inside the label tag, as you can transparently position the label without worrying about parental boundaries. Take the typical case of a container label:
So I prefer my labels and their corresponding inputs to be decoupled in the sense that neither contains the other. Another (slight) advantage to this approach is that you can cleanly assign multiple labels to the same input control, though I'm not sure when you'd want or need to do so.
http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1
I think using an explicit "for" attribute is cleaner than bundling the control inside the label tag, as you can transparently position the label without worrying about parental boundaries. Take the typical case of a container label:
<LABEL>
First Name
<INPUT type="text" name="firstname">
</LABEL>
So I prefer my labels and their corresponding inputs to be decoupled in the sense that neither contains the other. Another (slight) advantage to this approach is that you can cleanly assign multiple labels to the same input control, though I'm not sure when you'd want or need to do so.
> And I totally disagree about the semantics. Wrapping the label is much more correct semantically - it says this input and these words are related.
No, it says the input is part of the label, which is obviously nonsense. The opposite would work, but it's not legal. The @for attribute says they are related.
> I do not understand what you mean by "simpler scripting". Are you trying to make a special script action when they click the words?
Not necessarily click, but hover for instance. What if hovering over a label gave meta-information on the related field? As I noted, getting the field matching a label (and getting *whether the label has a matching field at all) is much easier via @for, it's a trivial getElementById dereference of label/@for.
No, it says the input is part of the label, which is obviously nonsense. The opposite would work, but it's not legal. The @for attribute says they are related.
> I do not understand what you mean by "simpler scripting". Are you trying to make a special script action when they click the words?
Not necessarily click, but hover for instance. What if hovering over a label gave meta-information on the related field? As I noted, getting the field matching a label (and getting *whether the label has a matching field at all) is much easier via @for, it's a trivial getElementById dereference of label/@for.
It's very late, so forgive me for impertenence.
But the "fast" thing to do is to add the long form declaration of the label into your templating function library.
In the future it would be much quicker to write something like: print checkbox('foo')
And get the 'fool proof': <INPUT type="checkbox" name="foo" id="foo"><LABEL for="foo">Include bar?</LABEL>
as output.
But the "fast" thing to do is to add the long form declaration of the label into your templating function library.
In the future it would be much quicker to write something like: print checkbox('foo')
And get the 'fool proof': <INPUT type="checkbox" name="foo" id="foo"><LABEL for="foo">Include bar?</LABEL>
as output.
Hardly fool proof since there are many legal names that are not legal IDs.
Also names can repeat, either within the same form (radio boxes for example, but other elements too), or in different forms. IDs cannot, and must be unique.
Also names can repeat, either within the same form (radio boxes for example, but other elements too), or in different forms. IDs cannot, and must be unique.
[deleted]
Nope, this does not work in general and is even worse for checkboxes and radios: it is very common to have groups of checkboxes and (especially) radios which all have the same name, differing only by their value. In that case, all checkboxes/radios will have the exact same id, which is quite obviously not correct.
And you can get that with any form field type.
Now you say "well you're using a cool form library, so it can just make ids unique per form and you get "checkbox1", "checkbox2", ..."
Except ids are unique per page, you could very well have a thousand forms with the exact same names in them, and you'll still need all of those inputs to have different ids.
And you can get that with any form field type.
Now you say "well you're using a cool form library, so it can just make ids unique per form and you get "checkbox1", "checkbox2", ..."
Except ids are unique per page, you could very well have a thousand forms with the exact same names in them, and you'll still need all of those inputs to have different ids.
We're comparing this to writing bare HTML by hand.
All of your criticisms apply equally to the technique it replaces.
Now since however, I didn't really specify what went into the checkbox function behind the scenes... lets assume.
1. It creates unique id variations. 2. It handles the case where you have multiple checkboxes with the same name. Perhaps by passing in differing parameters (e.g. checkbox(id='?', name='foo')).
You're criticizing an unspecified strawman example. Until someone actually goes out and writes this library, neither you nor I know how 'fool proof' it really is and what edge cases it leaves unspecified.
All of your criticisms apply equally to the technique it replaces.
Now since however, I didn't really specify what went into the checkbox function behind the scenes... lets assume.
1. It creates unique id variations. 2. It handles the case where you have multiple checkboxes with the same name. Perhaps by passing in differing parameters (e.g. checkbox(id='?', name='foo')).
You're criticizing an unspecified strawman example. Until someone actually goes out and writes this library, neither you nor I know how 'fool proof' it really is and what edge cases it leaves unspecified.
I'm generally not too terribly much of a stickler for accessibility, but a thousand times, yes. Unclickable labels are a GIANT pet peeve of mine, both as a user and a developer.
What's great about "accessibility problems" is that they're usually huge annoyances for everyone else too. Curb cuts are essential for bicyclists, closed captioning at sports bars, etc.
It's also frustrating for users that have js disabled in their browsers, that can't comment on a blog post! At least notify the user before hand! Plus the labels on the comment form are after the input fields - and the fields are inline, which makes the form hard to comprehend!
Honestly I don't see a reason to do special handling of people who disable javascript in their browsers these days.
Almost all of them are bots anyway.
Almost all of them are bots anyway.
"I don't see a reason to do special handling of people who disable javascript in their browsers these days."
Ironically enough, blind people who use screen readers might see a very good reason.
Ironically enough, blind people who use screen readers might see a very good reason.
Non JS users are statistically more likely to be bots than blind, so I don't see why that should matter.
And anyway JAWS use IE to read the page for the user, so it does support javascript.
And anyway JAWS use IE to read the page for the user, so it does support javascript.
I happen to prefer the web in the main with JS turned off. I may be in a minority here, but surely it's not much effort to design with graceful degradation in mind?
Seriously guys! A post about "labels for checkboxes" on the HN frontpage. In 2011.
No wonder people are complaining so much about HN.
Edit: Down votes? For trying to remind the community about the high quality of content and discussions on HN 2 years ago. OK.
No wonder people are complaining so much about HN.
Edit: Down votes? For trying to remind the community about the high quality of content and discussions on HN 2 years ago. OK.
Because it's a widespread problem across the web. Even from startups that read hacker news!
If this problem exists on some app which you [pay to]use daily, wouldn't it be better if you just dropped an email to them instead of discussing it here.
Please don't whine about downvotes.
Especially considering that your comment isn't grayed out at all right now.
Especially considering that your comment isn't grayed out at all right now.
There's a form I recall using multiple times that has labels for everything but a single checkbox: the box which, it so happens, defaults to "yes" for the installation of a piece of bloatware. I'm fairly sure it's in the Java installer. The practice disgusts me.
The word that comes to mind is "obv."
Obvious, yes. But I'm still amazed at how many people still don't use label tags. It's incredibly frustrating to not be able to click on a label, and I run into forms everyday that have this issue. What's even more frustrating is that there is such a simple solution. The only explanation is that people aren't aware of the existence of the label tag. So posts like this one are a good method to 'increase awareness'.
I don't know if it is obvious. I've been starting to use label tags for textboxes and didn't realise that value= wasn't good enough. Instead I had a label and a value= attribute that had a bit more information to help users... guess I'll move that to the label now.
And while we are at it, please enclose the form in a fieldset tag.
It is so much easier to read and understand.
It is so much easier to read and understand.