Inaccessible Label-Wrapped Form Inputs

Posted February 8th, 2008 by Mike Cherim

Not too long ago I wrote an article on keeping forms accessible. That was in September of ‘07. It’s an okay article, mostly accurate and helpful. I’ll stand behind its recommendations (it’s not that old), but one of those recommendations, an allowance actually, is seriously flawed. I am compelled and obligated to correct this. You see, I learned that a normal form-building practice of mine — wrapping a form input with its label — can seriously impact the accessibility and usability of a web form. Like hiding an input under a blanket.

In the article I mentioned that a label/input association can be made by wrapping the input with the label. As shown in this example:

<!--Don’t use this method. Example shown as HTML instead of XHTML-->
<label>Name
 <input type="text">
</label>

This is a valid method, and doing so ordinarily eliminates the need to add an id attribute to the input and a matching for attribute to the label. I also said that you can do both, as shown:

<!--Don’t use this method. Example shown as HTML instead of XHTML-->
<label for="name">Name
 <input id="name" type="text">
</label>

And up until a month ago or so that’s what I did. It’s an overkill method, but I didn’t think any harm came from it. I was wrong. Replicating the association isn’t a big deal that I know of, but wrapping the input with the label can have serious consequences!

Windows Eyes Goes Blind

A friend and colleague, Jim Thatcher, consulted with me on a site that I have made for a disability civil rights law firm (they’re adding content at this time so I can’t show you, but see it on my Projects page soon). This site is going to be a big deal of sorts in that it must pass muster, look great, highly professional, and be accessible to the nth degree — it is to be exemplary. Jim said I nailed it, the client is happy, and I’m really digging it I must confess.

But Jim did see one problem, on the contact form: Windows Eyes wouldn’t see the inputs with the labels wrapped around them. The Jaws screen reader didn’t seem to mind that arrangement, as was demonstrated by Nick Fitzsimons’ MP3 recording of my v2 demo form being read in forms mode (also hear virtual cursor mode), but Windows Eyes is apparently less tolerant. I can’t confirm it, but Jim’s knowledge of screen readers is vast, he made one, after all, so I’ll take his word for it.

The site is powered by WordPress, and for a contact form it uses my form plugin (now updated). I had made several modifications to it before Jim saw it because I was aware of some of its minor issues and it had to be spot-on. The form text was too verbose for comfortable reading, for example, so I fixed that. I also addressed the fieldset groupings, consolidating them more, making a smarter arrangement. Jim liked what I did, but the label issue he found had to fixed.

It was no big deal, taking only a few minutes, and I didn’t have to touch the style sheet, but I left one undone. A checkbox-type input still had the label wrapped around it so users could click on the text to check the box. A common practice. I did remove the for attribute. Unwrapping the checkbox input, I thought, decreased the ease of use for the majority user, so I was resistant to change it. I was wrong. Jim said it needed to be changed so I did. The text is still clickable — the for/id association I re-added appears to be adequate.

Limited Inputability for Safari on Mac

This is one of those really unwelcome obscurities that sometimes show up unexpectedly. For a while now I have had an occasional Mac user tell me that they couldn’t input text into some of the inputs of my v2 contact form. Others would randomly report that they could enter text, but it was difficult to get the I-beam text cursor into the field, difficult to focus the input. The feedback was inconsistent, though, and for the longest time I couldn’t understand what the issue was. A real head scratcher. I couldn’t replicate it on any Windows browser, including Safari for Windows.

I talked to some friends with Macs, running Safari, and they didn’t have a problem. A few of them use my form on their sites, all tested. This did nothing to help me solve the mystery. In fact I recall slipping into denial. Then one day a Mac user called me on the phone about some work. He told me he was on my site and trying to use my contact form but couldn’t get his cursor in the required name and email inputs. He was using the Leopard operating system running the latest Safari version. I asked him if he’d be willing to lend me a hand. He was.

Bear in mind this evidence is anecdotal, but while we spoke I moved the closing label to the end of the text, unwrapping the input. I asked him to refresh and try again. No problem, but the email input was still a no-go. We chatted some more, I moved that one, too. He refreshed when I was done, and it was miraculously cured as well. Anecdotal, yes, but damning all the same.

The Right Way

Based on this evidence, it seems clear this tried and true method is best:

<!--Good method to use. Example shown as HTML instead of XHTML-->
<label for="name">Name</label>
 <input id="name" type="text">

And to expand that a bit, here’s a simple form (many attributes aren’t shown):

<!--Good method to use. Example shown as HTML instead of XHTML-->
<form>
 <fieldset>
  <legend>Required</legend>
   <label for="name">Name</label><br>
    <input id="name" type="text">
   <label for="email">Email</label><br>
    <input id="email" type="text">
   <label for="message">Message</label><br>
    <textarea id="message"></textarea><br>
   <input type="submit" value="Submit">
 </fieldset>
</form>
<!--NOTE: No other elements — like lists — were harmed in the making of this form-->
<!--And, yes, I think the breaks are okay to use-->

This will read pretty logically and serve all users well. For a more complex form, see my version 3. View the source, of course, and, using your browser, see it with styles off. Please note that the checkbox input on that form is still wrapped with the label. I decided to wait for comments.

Test Bed

Here are some examples for testing.

Label-Wrapped Input Only

Label-Wrapped Input with Attributes

Attribute Association Only

Do you note any functional differences between these? I don’t.

Filed under Access Counts, Coding & Markup —

16 Responses to: “Inaccessible Label-Wrapped Form Inputs”

Dan Schulz responds:
Posted: February 8th, 2008 at 7:52 am →

Mike,

Thank you (and Jim especially) for confirming what I had personally suspected for a while regarding the proper use of labels and inputs. I don’t think you’ll have any problems with “unwrapping” the checkboxes/radio buttons, but if you do (or if Jim can demonstrate otherwise) I’ll be more than happy to make any changes on my end.

Again, thank you for the update and correction.
patrick h. lauke responds:
Posted: February 8th, 2008 at 11:33 am →

sadly, this is one of those annoying situations where (some) screen readers don’t follow the spec (which allows the wrapping). good to know, but at the same time may be worth passing this on to GWMicro (though whether or not they’ll care is another matter).
Alex responds:
Posted: February 8th, 2008 at 11:51 am →

Nice write-up Mike! I’ve always preferred to separate the label from the field, though I must admit it wasn’t for accessibility reasons. Rather I like having the control that it provides. It is much easier to use CSS to modify the placement of a label in relation to it’s form when the input field isn’t a child of the label, and the inclusion of the for attribute always ensures that labels apply focus to their associated form field when the user clicks on it, so functionality isn’t lost. After reading this article, I’m all the happier about the unexpected benefits that it provides.

Thanks for taking the time to not only solve an annoying issue, but for posting the detailed solution. It is much appreciated, and will benefit users and developers.

One thing that I’ve always wrestled with is radio buttons, where a label would logically surround the title of the group, but where each option would also be labeled. Here’s a rough outline of what I mean:

Radio Group Title
(o) Option Label 1
( ) Option Label 2
( ) Option Label 3

I end up setting the group label up as some form of header or bold text, and then the text associated with each radio button is wrapped in a label tag with a class that removes any label-specific styling (I typically render labels with bold text) to reinforce the understanding that the options are a part of the radio group. I hope that makes sense.

Have you found a good markup pattern for those instances?
Joe Dolson responds:
Posted: February 8th, 2008 at 12:22 pm →

Nice article, Mike! I’ve always done labels as separate entities from their associated input fields, and it’s nice to know that I’m in the clear. Nice to have a solid argument one way or the other on this issue.

One thing that I’ve always wrestled with is radio buttons, where a label would logically surround the title of the group, but where each option would also be labeled.

I can’t speak for Mike, but I’ve always grouped this kind of thing in a fieldset with a legend to label the group and labels to label the input fields.
Mike Cherim responds:
Posted: February 8th, 2008 at 1:17 pm →

I can’t speak for Mike, but I’ve always grouped this kind of thing in a fieldset with a legend to label the group and labels to label the input fields.

Although I find myself rarely using radio buttons, last time I did that’s how I dealt with them.
John Faulds responds:
Posted: February 8th, 2008 at 10:08 pm →

I do the same thing (separate fieldset and legend) for radio buttons/checkboxes.
Alex Jones responds:
Posted: February 9th, 2008 at 10:36 am →

Interesting, I hadn’t thought of fieldset as I always equated it’s use with multiple fields , textareas or sets of radio buttons and/or checkboxes textareas, but it makes a lot of sense. Thanks!
Helena Boylen responds:
Posted: February 9th, 2008 at 1:15 pm →

Thanks for this Mike - looks like I’ve got some changes to make, but it’s good to know
zcorpan responds:
Posted: February 10th, 2008 at 6:30 am →

good to know, but at the same time may be worth passing this on to GWMicro (though whether or not they’ll care is another matter).

Indeed. I’ve fired off an email to them.
zcorpan responds:
Posted: February 10th, 2008 at 6:38 am →

(Also reported bug 17276 to bugs.webkit.org.)
Mike Cherim responds:
Posted: February 10th, 2008 at 10:43 am →

@zcorpan: Thanks. I had been meaning to follow up on Patrick’s suggestion.
Mallory responds:
Posted: February 11th, 2008 at 6:56 am →

Alex, there’s another way (for those of us who like to have our fieldsets not wrap around a single question), though I wish I could really tell how it sounds:
Where you have your title, you could make it a label with a for. Following it is a div with the id matching the for. Inside the div are radio-label pairs, each label having a for matching the radios’ ids. Close div.

inside a form... Pick a radio

Radio 1 Radio 2 Radio 3

...more form...

I use the class of “matchingdiv” to remove the styles I’ve given all the other labels and inputs, since I usually want the default behaviour on these. I also use this for checkboxes and select dropdowns.

I read this somewhere back when I was first playing with forms. It was only someone’s idea and I’m not sure how great it works as far as association of labels and label-input groups, but it seemed good enough to try out. I didn’t like the idea of taking all the labels I didn’t need displayed and moving them offscreen (cause I also use this set-up for select groups, and having a label for each day, month and year seemed ridiculously repetitive when days were numbers and months were words…)

Actually, if someone’s documented a problem with this method, I’d be interested in reading it, as I haven’t found anything about it since I first read about this.
Mallory responds:
Posted: February 11th, 2008 at 6:58 am →

O, I used code tags above but I guess I did it wrong?
Mike Cherim responds:
Posted: February 11th, 2008 at 9:59 am →

@Mallory: Yes, sorry. You have to convert your code into entities. That’s okay though, you described your example well enough I think. You have mentioned wondering how it sounded, and that would depend on what mode the cursor is in. In virtual cursor mode everything is read, but in forms mode only form elements will be processed. Thus, any instance of conveying form organization or instruction via non-form elements may be confusing for some. The sound of the way Joe had described will be like this:

Fieldset Legend: Pick modes of travel Label/input: Train Label/input: Bus Label/input: Plane Label/input: Car Label/input: Bike Label/input: Walking

Read aloud, it would sound like this (I think):
“Pick modes of travel. Six radio buttons: Train, Bus, Plane […]”
Mallory responds:
Posted: February 13th, 2008 at 5:33 am →

Ah, so then using > label < for the main title and then wrapping a div around label-input pairs would be completely read-aloud in forms mode. I guess I’ve been in cursor-mode the whole time…
I suppose if I had a huge number of checkboxes or radios, a fieldset and legend works better, but I often find myself with lots of yes/no radios, so the label + extra div grouping seemed to make more sense than 10 fieldsets : )
Jermayn Parker responds:
Posted: February 13th, 2008 at 10:36 pm →

I can see this is similar to the conversation over at the WSG mailing list.
imo using the for for labels was definitely an over kill.

Thanks for explaining this as it now makes much more sense, I may however have to re-read your break article to help maybe answer my question about whats best to use for forms, p or li.

Sorry. Comments are closed.

Beast-Blog.com Inaccessible Label-Wrapped Form Inputs