Use the label element to make your HTML forms accessible

There are plenty of articles and tutorials that describe how to create accessible HTML forms out there. Despite that it is common to come across forms that do not use a single label element and forms that use label elements but do so incorrectly.

Forms that do not use label elements properly will cause accessibility problems for some users, which is bad. Apparently then, there is room for more writing on this subject, so here is a brief explanation of the label element, how it should be used, what problems can be caused by not using it, and what the benefits of using it are.

The label element associates information with a form control, letting the user know what purpose the form control has. Each label element can only be associated with a single form control, while a form control may have several labels associated with it. This could be very useful for displaying hints and error messages since it would let you separate those messages in the markup for much easier positioning and styling. Unfortunately my limited screen reader testing (JAWS 8.0 and VoiceOver) of multiple labels suggests that screen readers ignore them.

All visible form controls except buttons should have an associated label element (buttons are self-labelling). The label element can be associated with its form control either implicitly or explicitly.

An implicit association is created by putting the form control inside the label element, while an explicit association is created by giving the label element a for attribute with the same value as the form control’s id attribute.

I always use and recommend explicit association since it feels less awkward and more exact, and has better browser compatibility (IE 6 only makes explicitly associated labels clickable). I feel that explicitly associated labels also allow for easier styling and scripting.

I started this article by saying that the lack of label elements will cause accessibility problems. I wasn’t being specific, so you may be wondering exactly what those problems are. The main issues are:

  • Screen readers will have to guess which text to announce to the user by looking at things like the surrounding text and the form control’s title and name attributes. Sometimes they get it right, other times not. But the point is they shouldn’t have to guess.
  • People that can use a mouse but lack or have reduced fine motor control will have problems targeting checkboxes and radio buttons (they are really small). When checkboxes and radio buttons have properly associated labels, the label text will also be clickable, thus making the target area much larger and easier to hit. This obviously has usability benefits for all users.

Here is an example of an explicitly associated label element:

  1. <div class="text">
  2. <label for="firstname">Enter your first name:</label>
  3. <input type="text" name="firstname" id="firstname">
  4. </div>

The div element is what I normally use to group each label with its form control (for grouping several label + input combos I use fieldset elements where appropriate). It makes the form reasonably readable when CSS is off, provides a good hook for CSS, and makes sure my form elements do not contain any inline level elements (which is not allowed in strict doctypes).

If you want to display the label text above the input field instead of on the same line, it’s easy to use CSS to set the label element’s display property to block:

  1. .text label {
  2. display:block;
  3. }

Some like to use a br element instead, which also makes sure that there is a line break after the label when CSS is not supported. I go with the CSS approach, but use whatever works best in your particular siuation.

Some tutorials suggest using CSS to change the mouse cursor into a pointer when it is placed over a label element. It is a well-meaning addition that helps discoverability – many people are not aware that label text should be clickable.

There is a problem with that however, since not all browsers make labels clickable (Safari only started doing it in version 3, for instance). If the cursor changes to a pointer over a label it looks like the label is clickable, but when you click it nothing happens. My experience tells me that can be quite confusing. Sure, this is not a huge problem, but I still tend to leave the cursor alone for labels.

I hope this helps explain how the label element works and encourages some people to use it more.

Comments

1. November 19, 2007 by beth

Thanks for posting this! I don't often enough see the use of labels let alone correct labels in web forms. I don't really understand why anyone wouldn't use them because it gives you another control for styling. It's something I've ingrained in my company's UI team since arriving.

2. November 19, 2007 by Dan Schulz

Roger, once again you have hit the nail right on the head, and for that I thank you. I've been saying the same thing for about a year now myself (by the way, I fall into the BR element camp as far as DIVs vs BRs are concerned), but even today I'm still surprised and amazed by how many people do not know about the LABEL element, much less how to use it properly (for those who are aware of it, even if only vaguely).

Keep up the good work.

3. November 19, 2007 by Jason Reed

Great post. I've been using labels for a while now, and I have been evangelizing its use both as a styling element and for accessibility.

That being said, I haven't yet decided on a best practice for multiple inputs (such as three text inputs for a telephone number).

I have sometimes used hidden labels for the second and third inputs, but I don't think this is an ideal solution.

Any ideas on what to do?

4. November 19, 2007 by Kim Siever

I prefer implicit use. It requires less code, offers more flexibility for styling and makes the use of an id attribute optional on the form control.

5. November 19, 2007 by Beau

It's probably also important to note that you should always make sure the logical flow of your markup follows what the user expects. The label should come before the form input, because that's the semantic meaning. It's a label for that control. You can always use CSS to style it differently.

I nearly always place labels in my forms, not only for screen reader/other disabled users. I do it because I use them. I get frustrated when text that should be a label, isn't. I expect there's plenty of others like me.

It's a great accessibility feature, not just for the disabled, but everyone.

6. November 19, 2007 by Jason Reed

It's a great accessibility feature, not just for the disabled, but everyone.

Agreed.

7. November 19, 2007 by James

I've been doing this for a long time now. I tend to use a definition list to markup the form. Slightly more markup, but much easier to style.

8. November 19, 2007 by Jordan Ryan Moore

It's fairly easy to get around the non-clickable label issue (for those with JavaScript support). Just use JavaScript to loop through all labels on the page and add an onclick event that focuses on the label's form field.

9. November 19, 2007 by dougwig

I tend to use the label element implicitly (wrapping the input) but I was advised recently by a CSS coworker that this was not the preferred/more accessible use. Any idea if this is true?

10. November 20, 2007 by Cris

dougwig, I don't know about "less accessible," but here's my guess as to why explicit id-based association is preferred to implicit.

With implicit association, the form control is a child element of the label element. That makes it harder to isolate the label text from the control using CSS selectors.

So if you want to do something fancy, such as making the label text appear above the control, you end up wrapping the label text in an additional HTML element.

11. November 20, 2007 by Jon Humphrey

I use both explicit and implicit labels for forms. Explicit for most fields while implicit usually for radios and checkboxes. Even as the implicit use allows the area of the control to grow with the size of the label, I do understand the parent/child relationship issue but feel for those two field types it's worth the hassle.

I also place explicit labels before the field: div > label > field > /div; and implicit after: div > field > label > /div.

Also, for Jason Reed, I've gone the route when you have a group of fields, either use a fieldset and link the label to that, or do the same with a div. Attach either label to the container id. Anyone got one better?

Thanks Roger for another great thought provoking post!

Jon

12. November 20, 2007 by Kris

Jason,

Multiple text fields for a telephone number should send you thinking about whether that is usable for anyone. What format do you expect and what part of that goes into which field? Wouldn’t it be better then to have those fields explained by a label? That’s where your LABEL elements go.

Compare it to three entry fields to give up a date. How does a user know what the first field needs to contain? In Holland, the day of the month is commonly the first entered, but can a user be really sure about that? What if he is not of Dutch origin, or what if the website is not clear about it? Or, why would one have to guess at all?

A good practice is to include the order/syntax of the expected input, like "dd/mm/yyyy". Each part of that could be a separate LABEL element associated with a text field.

13. November 20, 2007 by Thomas Higginbotham

I recently started using <dl>'s for styling most form controls since most forms fall into the term/definition category. In addition to its semantics, you also get added hooks for styling. Of course, it may not look so hot when CSS is disabled but it's still perfectly usable.

14. November 20, 2007 by Brendan Falkowski

Each label element can only be associated with a single form control, while a form control may have several labels (which could be very useful for displaying hints and error messages if screen reader support for it was better).

I'm interested in cases where a form control would need several labels and how a screen reader would implement them. I add extra info like:

LABEL(Password SPAN(Must be 8-16 characters))

It's not ideal, but can provide extra info to users. Also it's style-able by CSS with relative ease (ex: visible while form control has focus).

@ Jon Humphrey - I use the fieldset tag to enclose groups of radio buttons or checkboxes, with a minor alteration. Use a label for each form control in the group, and then implement the legend tag to describe the whole grouping. This way you provide a description of the grouping while maintaining the accessible clickability for each form control.

15. November 20, 2007 by Kyle

I hate hate hate hate hate hate when sites don't implement the label element. Having gotten used to using it myself, I'm used to clicking on the text, not the actual radio or checkbox, and get annoyed when I have to go click again. More affordance is preferred, mmmm'kay!

Usually when I come across these sites, I just assume they haven't invested in a professional web developer, and then start to wonder about the quality of the rest of their site.

16. November 20, 2007 by Blake Haswell

Jason Reed:

When you have multiple form elements which you want to associate with one label (such as a date) I like to think a good solution is to use FIELDSET and LEGEND elements in association with LABELs. Like so:

<div>
    <fieldset class="date">
        <legend>
            <span>Delivery Date</span>
        </legend>
        <label for="day">Day</label>
        <input id="day" name="day" type="text" maxlength="2">
        <label for="month">Month</label>
        <select id="month" name="month">
            <option value="01">January</option>
            <option value="02">February</option>
            <option value="03">March</option>
            <option value="04">April</option>
            <option value="05">May</option>
            <option value="06">June</option>
            <option value="07">July</option>
            <option value="08">August</option>
            <option value="09">September</option>
            <option value="10">October</option>
            <option value="11">November</option>
            <option value="12">December</option>
        </select>
        <label for="year">Year</label>
        <input id="year" name="year" type="text" maxlength="4">
    </fieldset>
</div>

Then you simply use CSS to get rid of the LABEL elements or however you want to style it. A working example can be found here.

In case you were wondering, the DIV and SPAN are just styling hooks so I can get FIELDSET and LEGEND to play nicely cross-browser.

17. November 20, 2007 by Ryan van der Wal (NL)

I really get buggered - like all the rest of you guys it seems - when websites don't implement label tags. Usability wise it's a must nowadays. Especially with radio/checkbox fields on high-res monitors. I just can't be bothered to be really specific on where I click to check them. If it doesn't work? Well I just leave.

I was wondering what you guys think about the DL or DIV approach to forms. Was having a discussion with a fellow webdeveloper the other day. He leaned towards DL's and I towards DIV's . This just because a definition only has one right explanation and not multiple. Or is it just the old patato/pataato discussion. Opinions? If this is too much off topic ... please ignore.

18. November 20, 2007 by Carl

You keep producing such excellent articles – keep up the good work!

I was just wondering (not directly related to the article): Are there any stats on how many that have css disabled compared to those with js disabled?

I keep reading articles stating that you need to make sure your page looks okay with css disabled. I haven't come across anyone with css disabled and if this is a problem shouldn't we use tables to make sure they receive an acceptable layout like in the pre-css days?!

I believe we should keep our code semantic and simple for our own sakes – ease of development etc – and not because we believe people have css disabled...

A person using a screen-reader won't "see" the page anyway so the page doesn't need to look good without css for their sake as long as it is all semantic and accessible?

Is my reasoning correct?

19. November 20, 2007 by Darren

Label tags improve accessibility and usability for forms greatly. Even I click labels usually just as it's faster and doesn't require a precise click and I have no disability.

Not using labels is just a bad decision without any gain especially as they're semantically correct and provide an added CSS hook.

20. November 20, 2007 by Ben S

Hi Roger,

What's your reasoning behind using the <div> element for grouping labels and controls, rather than using <fieldset>? e.g. -

<fieldset class="text"> <label for="firstname">Enter your first name:</label> <input type="text" name="firstname" id="firstname"> </fieldset>

21. November 20, 2007 by Sophie Dennis

It had never occurred to me you could use multiple labels on a single input. Doh! If anyone can expand on how screen readers handle that it would be great. For more complex forms it sounds invaluable.

I was going to post Blake's solution to multiple input fields - correct use of fieldset and legend to group them, then labels for each input (hidden by CSS if that makes sense for sighted users) - but as you can see he beat me to it! I use this all the time on more complicated web-app forms and it works really well. The legend element can be a pain to style in some browsers (guess which?) but a smattering of absolute positioning can sort that out.

22. November 20, 2007 by Andreas

I'm with Kim Siever on this, I don't like cluttering my code with IDs and other "unnecessary" attributes. IE's the only one who doesn't get implicit labels isn't it?

If the label's for-attribute could work with the control's (mandatory) name-attribute instead I wouldn't mind associating labels explicitly but it really annoys me that I have to add an ID to the control as well.

Also, I almost always use a br to separate the control and the label, and paragraphs around my controls rather than divs (I'm really against using divs to display any kind of data, and the paragraphs have natural margins which is something I always want in my forms anyway).

Great article as usual by the way.

23. November 20, 2007 by Jules

The explicit method (using matching for/id attributes) enables a person to click on label text to activate that form control (check a checkbox, cursor in the text/textarea field, select a radio button option) in most browsers (Roger mentioned that Safari is only beginning to use this). The implicit method enables the same functionality but not in IE (I don't know about Safari): in IE, if you click on an implicit label, the form control is not activated. However, if you want to use implicit labelling and still offer the clickability of the label, use matching for/id attributes in implicit labelling.

24. November 20, 2007 by Brian LePore

Wow, I really love these comments. I wasn't aware that IE didn't make implicit labels clickable.

That having been said, I have never been able to figure out what to do for check boxes and radio buttons. For those fields implicit labels make more sense then explicit, because they benefit the most from the expanded clickability. That having been said, that means you're associating the value of the question being asked with the label, and not the question itself, like how explicit controls make sense for other types of input. The only way around it that I can figure is to have the question part also a label that has a value for the for attribute equal to the ids of one of the input, but this provides a pseudo-default value that I don't think I like. How do others handle this case?

Just to add, my co-worker tends to add br tags to separate his fields. I dislike them, but I am not going to push for a total change at this time. I'm just happy that we've moved over to making our application use multiple fieldsets, legends and labels, rather than one giant table.

25. November 20, 2007 by Simon Jessey

I use the fieldset element for grouping controls, but for individual controls I like to put them in a definition list, since they can be regarded as a name/value pair.

26. November 20, 2007 by Joe Sak

This topic was part of the morning session at Michigan State University's World Usability Day. Very good info! Thank you for continuing to support and enhance knowledge on browser experience.

27. November 20, 2007 by Scott Nellé

It's refreshing to see someone posting about html fundamentals; I've read enough about ajax and frameworks to last me quite a while. :)

I tend to use implicit labels, and along with other commenters I was wondering if that might be somehow less accessible, perhaps because certain user agents miss the association. I'm glad to hear that as far as you know that isn't the case.

So if you want to do something fancy, such as making the label text appear above the control, you end up wrapping the label text in an additional HTML element.

Although I get your meaning and agree that explicit labels can be more flexible, in this particular case a rule like label input { display: block; } should solve the problem. Of course, you'll probably want to exclude checkboxes and radio buttons from that. I usually use a class to do so.

28. November 20, 2007 by Angelo

Break tags? Honestly? I disagree. If what you're trying to achieve is presentational (and in this case, as it is described, it is) then it should live in the presentational layer of CSS.

29. November 20, 2007 by Angelo

And all this silly div/span/class/id nonsense would vanish if certain browsers would opt to recognize attribute selectors. Ahem.

30. November 20, 2007 by Mike Cherim

Excellent post, Roger. Typically I apply both implicit and explicit associations, knowing full well it's not necessary of course. Just something I tend to do. I don't think any harm comes from it.

I'm sort of surprised you organize your groupings in a div instead of a fieldset.

31. November 20, 2007 by Edwin

Very interesting! Thanks!

32. November 20, 2007 by Yordan

What if i don't want to show the label but still want the form to be accessible and to attach label for the screenreaders? Is it ok to use "display:none;" ?

33. November 20, 2007 by Jules

Yordan:

[Some screen readers ignore display:none] (http://www.456bereastreet.com/archive/200711/screenreaderssometimesignoredisplaynone/)

34. November 20, 2007 by Jules

Oops! Markdowned it wrongly.

Some screen readers ignore display:none

35. November 20, 2007 by pauldwaite

Just use JavaScript to loop through all labels on the page and add an onclick event that focuses on the label's form field.

Ha ha! Yeah! You can also get rid of all those annoying link tags this way too. Just use spans with the URL in the title attribute, then loop through them all and add an onclick event that loads the destination.

Honestly. It is 2007, right? I didn’t dream the last 5 years?

What's your reasoning behind using the <div> element for grouping labels and controls, rather than using <fieldset>?

Not to put words in Roger’s mouth, but I think a fieldset is meant to group multiple fields, rather than one field and its label. There isn’t an HTML element that’s meant to group a field and its label, hence the use of the division tag.

36. November 20, 2007 by pauldwaite

The legend element can be a pain to style in some browsers (guess which?)

legend is a pain to style in all browsers :)

37. November 20, 2007 by Roger Johansson

beth:

I don't really understand why anyone wouldn't use them because it gives you another control for styling.

Me neither. Most likely it's because they never heard of the label element.

Jason:

That being said, I haven't yet decided on a best practice for multiple inputs (such as three text inputs for a telephone number).

I try hard to avoid multiple inputs for something that is really a single input from the user's point of view, but when I am forced to use them I tend to use hidden labels for some inputs. It depends on the situation.

Beau:

The label should come before the form input, because that's the semantic meaning.

Unless the input is a radio button or a checkbox :-).

dougwig:

I tend to use the label element implicitly (wrapping the input) but I was advised recently by a CSS coworker that this was not the preferred/more accessible use. Any idea if this is true?

Yes, it is true. Implicit association does not make labels clickable in IE 6. You can still wrap the input in the label if you also use for and id though.

I thought I was pretty clear about explicit association being better, but since several people have missed that point I think I'd better update the article :-).

Brendan:

I'm interested in cases where a form control would need several labels and how a screen reader would implement them.

If a form is returned with error messages it would be great to use additional label elements to associate each message with its control. Unfortunately the screen readers I have tested with (JAWS and VoiceOver) do not understand multiple labels. Graphical web browser do though (at least those I tried in).

Blake:

When you have multiple form elements which you want to associate with one label (such as a date) I like to think a good solution is to use FIELDSET and LEGEND elements in association with LABELs.

Yes, that's how I do it.

Ryan:

He leaned towards DL's and I towards DIV's . This just because a definition only has one right explanation and not multiple.

I think using definition lists for forms is a bit of a stretch, but it's probably better than using tables. I go with fieldset and div elements.

Carl:

Are there any stats on how many that have css disabled compared to those with js disabled?

Not that I am aware of.

I keep reading articles stating that you need to make sure your page looks okay with css disabled. I haven't come across anyone with css disabled and if this is a problem shouldn't we use tables to make sure they receive an acceptable layout like in the pre-css days?!

We don't need to go out of our way to make pages look nice when CSS support is missing. But if we use HTML properly that tends to sort itself out pretty well without doing anything special. It's not about making pages look as nice as when CSS is there, it's about making sure they are readable and understandable.

Ben:

What's your reasoning behind using the div element for grouping labels and controls, rather than using fieldset?

Well, a single set of one label and one control is not a group of inputs, so a fieldset would just get in the way. When I have groups of radio buttons or checkboxes I do use fieldset + legend. The example here is just what I use for each individual pair of label + control.

Sophie:

If anyone can expand on how screen readers handle that it would be great. For more complex forms it sounds invaluable.

Unfortunately they don't handle it very well according to my limited testing.

Brian:

That having been said, I have never been able to figure out what to do for check boxes and radio buttons. For those fields implicit labels make more sense then explicit, because they benefit the most from the expanded clickability.

Both implicit and explicit association make labels clickable in all browsers but IE 6 (not sure about 7), where only explicit association works.

Scott:

I tend to use implicit labels, and along with other commenters I was wondering if that might be somehow less accessible, perhaps because certain user agents miss the association. I'm glad to hear that as far as you know that isn't the case.

I'm afraid that implicit label are in fact less accessible than explicit labels. See my comments above :-).

Mike:

I'm sort of surprised you organize your groupings in a div instead of a fieldset.

But I don't ;-). See my comment above about this just being a single label + input combo, not a group.

That said, I don't always use fieldsets. Hearing the legend before each form control can get tedious in some cases. Yordan:

What if i don't want to show the label but still want the form to be accessible and to attach label for the screenreaders? Is it ok to use "display:none;" ?

No. Use position:absolute;left:-9999px; or some variation of that instead.

38. November 20, 2007 by pauldwaite

semantic meaning

Oof. “Semantic” means “relating to meaning”. The phrase “semantic meaning” is therefore a bit redundant.

39. November 21, 2007 by Mike Cherim

@Roger:

But I don't ;-). See my comment above about this just being a single label + input combo, not a group.

Good point. Thank you.

40. November 21, 2007 by Stevie D

@Jason Reed:

That being said, I haven't yet decided on a best practice for multiple inputs (such as three text inputs for a telephone number).

Don't use multiple inputs! Unless you are going to immediately process the data and so absolutely have to have it in sections, allow users to enter the information in whatever way they want.

Several times I've tried to enter a telephone number when using a website based abroad (or international) and it won't allow me to enter a UK number in any sensible format (if at all). Dates could be split, and if you're expecting an international audience it might be better to do that. Alternatively, try to parse whatever input you get (eg traintimes.org.uk accepts dates entered as, eg, "tomorrow", "next thursday", "22nd of march", as well as the more common "21/11/2007" or "2007-11-21") - this can cause problems if you get dates in both d/m/y and m/d/y but is more user-friendly apart from that.

41. November 21, 2007 by Scott Nellé

Roger:

I'm afraid that implicit label are in fact less accessible than explicit labels. See my comments above :-).

Duly noted. I though I had read a comment from you that said you didn't know of any issues, but I guess I was imagining things. Thanks for setting that straight.

42. November 21, 2007 by Jason Reed

Don't use multiple inputs! Unless you are going to immediately process the data and so absolutely have to have it in sections, allow users to enter the information in whatever way they want.

Ah, if only it were that easy! I wish I had that level of control over the way my clients do things sometimes.

I have strongly suggested that several times, only to be shot down by their IT department/development crew. Oh well.

And thanks to everyone for the suggestions above- I'm still parsing them to figure out what I think is the best option.

43. November 22, 2007 by jaysen marais

Ok. So the above comments generally agree that labels are a Good Thing. No dispute there.

What happens when you want to use a label to describe a bit of derived or permanently read-only information in a form (such as 'last modified date') which is will be marked up as text, rather than an input (please don't suggest a read-only text input)?

To my way of thinking, a label seems like a better semantic fit than a dt/dd pair or a header. Plus it has the virtue of consistency (i.e. every datum in a form has a label).

I suppose I'm asking whether screen readers and their ilk support a label attached to a span and if so, what kind of support do they offer? If not, is it something worth campaigning for, or is there a superior alternative?

44. November 22, 2007 by lyhana8

Hi, like James I tend to use definition list to build my form because that seem more meaningful for me and it's easier to style.

<dt><label for="pwd_chk">password verification: </label></dt>
    <dd>
        <input id="pwd_chk" name="pwd_chk" type="password" size="30" value='' />
        <label class='hidden em'> (obligatory to register).</label>
    </dd>

A way I use to increase accessibility, is hiding a second label using parental background-color value, then change it on :hover to another/visible color.

.hidden { color: $lighter_grey; }
*:hover+.hidden { color: inherit; }
#logger dt:hover+dd>.hidden { color: inherit; }
45. November 27, 2007 by Stomme poes

I have the same problem as Jason Reed. I have a date label, then three option dropdowns. There is no confusion with months and days (this is a Dutch site-- but we just have the names of the months). A seperate label for each complicates the form, looks ugly, and for even a blind Hollander, not necessary. I will try both of the two best options I've heard: hiding it away like a rat under the rug with CSS with margin-left: -gazillion, and I will try the wrapping div with the appropriate ID. However, I can only test in JAWS, which will do whatever IE6 does (or 7...). I'm thinking the div wrapping is in this particular form the better idea. If they were text-inputs, the hidden labels (or visible) would make a lot more sense, but with select dropdowns... just looks feels stupid stupid stupid.

46. November 30, 2007 by Christian

Although I don't use tables for layout sometimes when building forms I can't help but have the thought cross through my mind: "This really is tabular data here. It's just waiting for some of the data to be filled in." Is it just me or does that kind of make sense?

47. December 4, 2007 by Ryan

One good way to get a feel for the way JAWS reads forms is to use the FANGS extension for Fire Fox (This is no shameless plug!).

I've found it to be very much inline with what the real JAWS reads aloud to users. This is a great way to approach complex accessibility problems.

@Roger: I love this write-up. I've been dealing with accessible forms for the last week. Perfect timing! Thank you!

48. December 5, 2007 by Nathan

Well, until I stumbled across this site I had never heard of label - and I know that was true of a lot of people. However, I think this is a great idea and so I have now changed all my forms to use this tag. Hopefully this will improve accesibility.

As for grouping labels and controls together when it's just a label control pair I also use a div and then a couple of span tags so that I get the benefit of nicely lined up labels and controls without the use of tables. It works a treat

49. December 11, 2007 by Rollo

So: [label for="[name]" [name=""]]. At last! I understand the label element.

50. December 11, 2007 by Roger Johansson

Rollo: Not quite. The value of the for attribute needs to match that of the id attribute, not the name attribute.

51. December 18, 2007 by Rollo

That contradicts the first example above, no?

52. December 18, 2007 by Roger Johansson

Rollo: Not sure I follow. In my example, the value of the label element's for attribute matches that of the input element's id attribute.

53. December 19, 2007 by Rollo

Yup, you're right, I'll put it down to a case of "divslexia". Got it, thanks.

54. January 3, 2008 by Tom

Great article and great website in general. Thanks for sharing your knowledge with us!

Sorry, comments are closed for this post.

Information, sponsorship, and externals

About the author

Roger Johansson is a Swedish web professional specialising in web standards, accessibility, and usability. More about me and this site.

Subscribe

Looking for web hosting?

Try DreamHost!

Use the promo code 456BEREASTREET3 to save USD 20 when you sign up!

Latest articles

Validation statistics from Nikita the Spider Comments off
An analysis of the sites crawled by the bulk validation tool Nikita the Spider during March 2008.
Authentic Jobs API and Affiliates program Comments off
The Authentic Jobs job listing service now has a public API and an affiliate program.
What does Acid3 mean to you and me? Comments off
Opera and Apple have announced that their web browsers pass the Acid3 Browser Test, but how will that help web designers and developers?
Designing Web Navigation (Book review) Comments off
Learn the fundamentals of navigation design and design better navigation systems for large and small sites as well as for web based applications.
DOMAssistant bundle for TextMate Comments off
To save keystrokes and speed up development I have created a DOMAssistant bundle for TextMate.
First impressions of Internet Explorer 8 Beta 1 Comments off
My impressions after trying out Internet Explorer 8 Beta 1 for a couple of days.

More articles

Favourites, here and elsewhere

Affiliation

  • NetRelations
  • Kaffesnobben
  • Dagens recept
  • 9rules network member

Support this site

Show your support by buying a book or two from SitePoint or getting me something from my Amazon Wish List.