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.

Posted on November 19, 2007 in (X)HTML, Accessibility

Comments

  1. 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. 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. 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. 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. It’s a great accessibility feature, not just for the disabled, but everyone.

    Agreed.

  7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. And all this silly div/span/class/id nonsense would vanish if certain browsers would opt to recognize attribute selectors. Ahem.

  30. 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. Very interesting! Thanks!

  32. 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. Yordan:

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

  34. Oops! Markdowned it wrongly.

    Some screen readers ignore display:none

  35. 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. 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 (Author comment)

    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. semantic meaning

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

  39. @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. 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. 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. 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. 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. 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. 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. 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. So: [label for=”[name]” [name=”“]]. At last! I understand the label element.

  50. December 11, 2007 by Roger Johansson (Author comment)

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

  51. That contradicts the first example above, no?

  52. December 18, 2007 by Roger Johansson (Author comment)

    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. Yup, you’re right, I’ll put it down to a case of “divslexia”. Got it, thanks.

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

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.