Tips for Keeping Forms Accessible
Web forms are generally accessible if you build them using the proper elements. If you don’t use the proper elements, though, then right out of the starting gate their inherent accessibility is diminished or even lost completely. This article assumes that you have a basic working knowledge of the various form elements and how they are used. This article’s main objective will be to offer some tips for keeping your forms accessible, and in some cases, making them even more accessible than they are by default. So, here are the tips, in no particular order. Oh, and try not to mind my headings… I was feeling creative.
Keep ‘em in Fieldsets — Don’t Raise Free-Range Forms
Group sets of form controls and inputs (fields) using the fieldset element. Doing this cuts down on the possibly of causing confusion as it helps users identify the form’s elements from the surrounding page content — keeps the herd in the pen. This is also essential for those who use screen readers as they can get a better feel for these (normally) visually logical groupings.
Always Provide Really Short and Concise Legends so You Don’t Make Your Legends Too Wordy for Screen Readers Users Because Wordiness Can Be Evil… Yeah
Provide a legend element with each fieldset. Please note that legends should probably be short (though this is sometimes difficult) as they can be read aloud by screen reader users before each and every input in a given grouping — there will be more on this. As an example, I tend to employ fieldsets to organize required inputs from those which aren’t required. The legends state “Required Contact Info.” To screen reader users, the inputs in these fieldsets are prepended with the legend. So, if I have an input that says “Email” in its label, the screen reader user (in forms mode) may hear something to the effect of “Required Contact Info, Email, tab and type text.”
Heading: Associate Controls with Labels
Most inputs should have a label element telling the user what that specific control needs or what it’s used for. I don’t do this on my submit-type inputs — though I’ll often add an alt attribute — but the fixed value of that input-type should suffice in providing the information the user needs. But all those other inputs, like the text-type inputs, for example, cry for labels to ensure accessibility. To take this a step further, these labels need to be associated with their controls. This is done two (three) ways:
- Wrap the input with the label element to make a physical association.
- Use the label
forand inputidattributes to make a machine-readable association. - Or you can do both (it’s what I generally do though it is overkill). Whoops, read update.
For instance, let’s assume you have a text-type input that is meant to collect the user’s email. To mark it up, using my patented dual overkill method (since this shows both), you’d do this.
<label for="email">Email <input type="text" name="email" id="email" size="22" maxlength="60" value="" /> </label> <!-- Note: Always backup the maxlength attribute with server-side script for added security. Also note that I used a self-closing slash on this input example as the example is XHTML. -->
Wow… Even More On Labels
Another tip as it concerns form labels is to put the label content before text-, password-, browse-, image- and other-type inputs (with or without a break element, but this will be an up-and-coming article). On radio buttons and checkboxes, though, the label text should come after the input. Doing this will ensure better accessibility. Example:
<label for="opt-in"> <input type="checkbox" name="opt-in" id="opt-in" value="opt-in" /> Opt-in </label>
Accommodating Lazy “Autofill” People
Use a common language for the input name attributes like “email” for email, “web site” for web site, “address” for address, etc. If you do this those who like and use “autofill” — which is usually a tool bar function to pre-fill common inputs with previously inputted data — will be appreciative (the opposite of how they feel about the heading above). If you were to get creative and provide an identifier for the name attribute for the “Email” input, for example, with something like name="YeOldeEmailAddy", autofill wouldn’t recognize it and the user would have to input the data manually, at least that first time since their autofill would recognize it thereafter.
Add Moderate Styling
When it comes to styling forms, some people feel strongly that it is a practice that should be avoided. The rationale being that there are so many differences in browser form rendering abilities that it’s not worth the effort and that nothing of value comes from it. I disagree to a point. I certainly agree that the rendering differences can be a real challenge — with some being downright impossible — and that some form elements are probably best left alone as styling them may be more aggravation than they’re worth. The disagreement applies to the complete abandonment of all styling attempts. You see, I think there is some value worth going after. Namely I mean focus styling as this is really helpful to keyboard users.
I used to go completely overboard when it came to form styling, but I realized it as a faux pas as I matured more into this field. Plus I think Roger Johansson mentioned it to me one day, though for the life of me I don’t recall if it was on his site or in an email. Anyway, I stopped doing that. But I didn’t want to stop styling altogether for keyboard users — and eye-candy. Now I keep it to a dull roar. Don’t misunderstand, I am not saying to not supply background-colors outside of the form elements, and more subtle colors inside if you wish, nor am I saying you can’t have some fun and float a textarea like I did on a client’s property sale site’s summary page. (Note that the colors on that form are about as wild as I will get nowadays and I think a much better example of useful subtlety can be found on my primary form.) I think it’s pretty safe to replace text-type input borders, then you can add :focus (as the minimum) to your style sheet to achieve basic accessibility/usability focus. To get that to work for Internet Explorer (IE) 6 and older, though, you’ll need to add a class to the :focused element in the style sheet (see below) and use some JavaScript like this (yeah, help yourself). In the example below I will add a little background color change as well.
/* Use classes on inputs to specify and avoid unwanted issues */
input.text {
border : 1px solid #99cc66;
background-color : #fafafa;
}
/* The second entry, the .focus class, is for IE6, but it is not added to the markup */
input.text:focus, input.text.focus {
border : 1px solid #000;
background-color : #fff;
}
That’s about it.
Use/Don’t Use Placeholder Content (?)
I don’t know if I can call this one a tip, but I want to talk about it. I don’t use placeholder content in my forms, even though it is a requirement of the current Web Content Accessibility Guidelines (WCAG 1.0), but apparently I should. Not characters per se, but a single space may improve accessibility for Braille readers and legacy screen readers — the latter needs it to detect the input. It seems that a single space may indicate a “fill in the blank” that requires user-inputted content, as noted by Accessites colleague, Mel Pedley. Gez Lemon offers an article which discusses this very thing. In researching this topic I did find a WebAim 2003 discussion thread on the topic I found interesting as it discusses even more alternatives.
I’m not sure if this is going to be part of the WCAG 2 Working Draft, I think I found it, but it was so unclear that I couldn’t be sure it was input placeholder text they were talking about. Maybe it’s me, but it’s rough reading in my opinion. If you, dear reader, knows one way or the other if the WCAG 1.0 checkpoint 10.4 is slated to be carried over to the WCAG 2.0, please speak up.
Whoa, Don’t Over-Build
Forms in tables, forms in lists, inputs in paragraphs, divs, divs, and more divs. I’ve seen so much added form structure that if combined it might rival the Great Wall of China. And 99% of it is mostly unnecessary. All you really need are the form elements, and maybe a single div wrapper, or an offset div, or maybe a legend span, but that’s about it. I’ve heard well-reasoned and seemingly logical arguments as to why putting a form in a list is a good thing, but I don’t really agree. The only exception that I can imagine is an online test or survey where the questions are supposed to be answered in a given order. But even then, the natural ordering of the form should satisfy any logical ordering requirements. Speaking of ordering…
Dude, What About Tabindex?
Avoid it unless you absolutely need to override the natural order of a form. But be careful. Once you monkey around with tabindexing you have to maintain it. If an input is added, for example, depending on where it fits in and the size of the form, it can be a royal pain). Altering the natural order can also confuse users. As a result, based on research, their heads can explode.
Assigned Accesskeys Can Kill Access
Don’t assign accesskeys for the users on your site. In doing so, a person trying to input an accented character in their name into your form may end up on another page, totally confused. This can be a form accessibility concern. Let them assign their own accesskeys with a script like Thierry Koblentz’s as one of several out there. Tip: Be sure to begin with null values.
Avoid Additional Instructions. Intuitiveness Rules!
Putting user instructions and making sure they are accessible in a form can be a wicked challenge if the form is complex, unintuitive, or requires additional instruction. An example of this last item might be something like: *denotes a required field. The problem is twofold. First a user can access a form directly. Thus if you have special instructions before the form, outside of the form element, it may be bypassed by the user and something important could be missed. But, the second catch, if you put the instructional content inside the form and not within one of the actual form elements (legend, label), it can also be missed if, for example, the user is using a screen reader in what’s known as “forms mode.” To get a better feel for this, you can listen my moderately styled demo form being read by the Jaws 8 screen reader in forms mode, then in (the default) virtual cursor mode. Recordings courtesy of Nick Fitzsimons.
When it comes to the “required” field example I think the best bet is to add it to the label text or to the legend the way I do on my forms. It’s not a perfect solution in that it can be deemed somewhat redundant (because the legend is read before each label), but considering the fact it is a viable solution to keeping my forms accessible, I feel it may be a worthy redundancy.
John Faulds responds:
Posted: September 11th, 2007 at 1:00 am →
Re: required fields - I like the method I first saw on a Sitepoint article about using an asterisk (which most sighted people understand to be required) as an image with an alt attribute of ‘required’.
And as far as fieldsets go, I find that you need to think about them a bit - not all forms are easily broken up into logical groupings. A good example is a simple blog comment form - this one especially illustrates the problem. If you use a fieldset, you have to use a legend and in this case, screenreader users are going to hear ‘Enter your details’ before each input. They already know they have to enter their details because the form’s preceded by ‘Post a comment’ and presumably most people know when they encounter a form that they have to enter details, so the legend seems a bit redundant in these sort of situations to me. Better to just use a div I reckon for shorter, simple forms.
Ross Bruniges responds:
Posted: September 11th, 2007 at 4:39 am →
The autofill tip is one of those “do’h” moments when you read something that isn’t really talked about in books but is so bleeding obvious when you are told it!!!
Good article - lots of nice points well explained :>
JackP responds:
Posted: September 11th, 2007 at 6:17 am →
Where did you find the placeholder reference in WCAG 2? I couldn’t spot anything…
The current internal working draft of WCAG 2.0 does not appear to have anything about place-holder characters, although it does have something which will help your autofill crowd:
I don’t use placeholder content myself: I’m aware it’s not perfect for legacy AT, but then I don’t really expect to cater for NN4 either - what it gets, it gets because of page structure - I’m not going to specifically go out of my way to cater for out-dated technologies. But that’s just me, maybe!
As for the rest of it: well, I don’t worry about form styling too much, but I’m 100% with you on the rest of it.
Sarah Bourne responds:
Posted: September 11th, 2007 at 9:32 am →
Required fields:
I wish your cluster solution could always work - it’s so tidy! - but it seems it would break other logical grouping priorities all too often. For instance, it would be awkward and annoying if an optional “apartment” field or additional address lines were put in a different cluster than the rest of the address information.
Over-build:
Our usability folks really, really want to have text and drop box labels be right-aligned, with the the input boxes aligned in a nice vertical stack. Everybody knows how to do that in a table, but table-less solutions seem to require DIV proliferation and lots of styling code. I spent too much of yesterday trying to discover an elegant (minimal HTML/CSS, totally accessible) solution. Have you worked on anything like this?
This is a great article - thanks!
JackP responds:
Posted: September 11th, 2007 at 9:48 am →
Sarah, if it’s any help, this is how I’ve done it before:
<p><label for="Name" class="label">* Name</label>
<input name="Name" id="Name" type="text" class="input" />
</p>
with the following bits of CSS
fieldset#name p{clear:both}.label {display: block; float: left; text-align: right; width: 12em; margin-right:20px;}
.input {display: block; float: left; }
Okay, I’m sure it’s possible to do it better as I’ve not looked at it again for some time, but that appears to do the job - just tweak the values to suit, and it doesn’t suffer from divitis.
Mike Cherim responds:
Posted: September 11th, 2007 at 10:01 am →
@John: I think I saw that asterisk image solution before, from you is my guess. I think it’s fantastic idea. Regarding fieldsets, I feel one should always be used, even on a small form like a search box. The legend would say “Search,” the label would say something to the effect of “Enter keywords.” On my contact form since it’s larger, I use a fieldset and telling legend to contain the whole form (as one big unit), then I used smaller fieldsets for my sub-groupings. The advantage is the first legend isn’t read as there are no labels/inputs in it directly. I think this is a decent practice, though certainly not one-size-fits-all.
@Ross: Thanks. I discovered that by accident. When I produced my contact form for distribution I had a honeypot (a tempting but bogus offset-hidden input to trick bots) with the name “e-mail” so that it would seem as real (tempting) as possible. It choice of name was a bad idea: e-mail or email both work for autofillers so a lot of people were being trapped because their autofill would enter data in that offset-hidden input. Whoops. I changed it to p-mail and that did the trick.
@Jack: I can’t find the link, but I started at Google, ended up on some live “testing” pages where I thought I found a vague reference, followed it to the spec. That’s where I had my huh? moment. regarding dated legacy equipment, I’m with you on that. Time to upgrade from NN4, but the braille readers concern me because that’s current.
@Sarah: I agree. Each form needs to be handled differently. My solution works nicely on my contact form, but I can see many cases where it wouldn’t work (like your required address/optional apartment scenario). Regarding the label placement, it was my understanding that right-aligned label text is good if the label is on the same line as the input, but I have also heard that putting the label above the input (using a break, not CSS), is also quite usable. That’s my understanding anyway. This solves the problem of the placement. For single line placement the only thing I can think of to get the labels to align to the right and keep all the inputs left-aligned would be either to make sure they are all the same size then center the text in the form. The only other way I can think of is to separate the labels from the inputs, and using the form attribute might help some negotiate this, but I do think it would be weak at best. I don’t think any other non-table solution would fly. But using a table for it to get the look right for usability would probably have a negative impact on accessibility just like separating the labels from the inputs (I guess there you’d use the “
for” attribute and a “headers” attribute in the table cells to tie them to the label-containing table headers (th).John Faulds responds:
Posted: September 11th, 2007 at 6:00 pm →
But won’t screenreaders read that out as “Search enter keywords”? If that’s the case, I’d think that phrase might lead to confusion for some. Or maybe I’m misunderstanding how screenreaders handle this?
Doe each smaller fieldset have a legend as well?
Mike Cherim responds:
Posted: September 11th, 2007 at 6:28 pm →
@John:
It would read just like this, (followed by the tab and type text instruction), but to a screen reader user using the form I think they wouldn’t have a problem with it due to experience. When I listen to those recordings I get lost wicked easy because it’s to fast for me, but if a screen reader was something I used everyday I imagine I’d get used to it quickly.
Yes. The Required and Optional groupings. What’s being read in the recording is this demo form.
Dennis responds:
Posted: September 11th, 2007 at 9:39 pm →
The WCAG Samurai says you should not use placeholder text in input fields and specifically to ignore the WCAG 1.0 guideline that says to use it.
For the asterisk issue, I’ve explained what it means at the beginning of a form, then when adding it next to a form label wrap it with an abbr tag with the title “required”.
Couple questions:
1) What do you think about coding Fieldsets and Legends, then hiding them with CSS so that only screen readers recognize them? Sighted folks get the spacing result. My day job is with a company that does this and it irritates me.
2) You say:
Can you explain why?
Mike Cherim responds:
Posted: September 11th, 2007 at 10:44 pm →
@Dennis: It has been my understanding for a long time — via the grapevine — that the placeholder text requirement was going to be abolished. Though the presence of a space may be something I will incorporate into my forms. Can’t hurt, and it may help. The PHP
trim()function should mean I won’t have to alter the script on required fields. It should trim the space and the submitted value on default-state inputs should still be null.Going that route I think a defining instance, would be better, assuming it could be picked up.
I guess I’m okay with that if it’s intuitive and smartly done, especially with legends. I am doing that on a big site I’m still building (but 99.9% done). The site has a shop and the shop product form legends are hidden off screen since there was really no need to see them — but I had to put them in a
spanto do that. And on my contact form I have adivthat contains the honeypot input and explanatory label. Sighted users don’t need to see it at all, whereas screen reader user specifically need to read that label so they don’t fill in the input (turn of styles on the form demo page to see it).2) Re: label text placement on radio buttons and checkboxes:
In that situation the label is read before the input quite naturally so maybe it’s more of an aesthetics thing. For some reason I think there may be a usability factor to take into consideration, but I don’t remember exactly what that is or where I might have come up with it.
Nachlese September 2007 - Die Seiten des Monats | Nachlese responds:
Posted: October 9th, 2007 at 2:06 pm →
[…] Tips for Keeping Forms Accessible Eine Übersicht von grundlegenden Prinzipien des zugänglichen Designs von Web-Formularen. Insbesondere ist es sinnvoll, zusammenhängende Elemente mit fieldset-Tag zu gruppieren, mit legend-Tag zu benennen und mit label for miteinander zu verknüpfen. […]
Best of September 2007 | Best of the Month responds:
Posted: October 9th, 2007 at 3:13 pm →
[…] Tips for Keeping Forms AccessibleThis article’s main objective will be to offer some tips for keeping your forms accessible, and in some cases, making them even more accessible than they are by default. […]
lost node » Blog Archive » Best of September 2007 responds:
Posted: October 9th, 2007 at 7:28 pm →
[…] Tips for Keeping Forms AccessibleThis article’s main objective will be to offer some tips for keeping your forms accessible, and in some cases, making them even more accessible than they are by default. […]
Funky Penguin News » Blog Archive » Best of September 2007 responds:
Posted: October 11th, 2007 at 2:50 am →
[…] Tips for Keeping Forms AccessibleThis article’s main objective will be to offer some tips for keeping your forms accessible, and in some cases, making them even more accessible than they are by default. […]
dharma responds:
Posted: October 12th, 2007 at 3:17 am →
Assigning access keys, I thought this was a great tool for people with disabilities for navigation. The article on form accessibility proved me otherwise and it is true. If people need to input their names in a form field, they may end up in another page!
行搏客 » 2007年9月最佳 responds:
Posted: November 16th, 2007 at 12:54 pm →
[…] Tips for Keeping Forms Accessible This article’s main objective will be to offer some tips for keeping your forms accessible, and in some cases, making them even more accessible than they are by default. […]