One of the sessions I attended at the 2008 Adobe MAX conference in San Francisco was Creating Attractive, Usable, and Accessible Forms, presented by Rob Huddleston. I went to this session as part of my current drive to improve my user interface (UI) and Web accessibility skills. In this post I’ve collected a few do’s and dont’s that I jotted down during Huddleston’s presentation. As was the case for me, you’ll likely already know some of these, some might serve as reminders of something you already knew, and hopefully a couple will make you think about rewriting some of your HTML forms today. Click here to view an example of some of these ideas.
An HTML form should…
- Provide good instructions. Indicate to the user what they should do, what will happen next, etc.
- Clearly indicate which fields are required. Use of asterisks, bold font, or a different font color is the standard. Also have a note that indicates that these formatting changes mean the fields are required.
- Explain why specific data is being requested. This is particularly important, as you want to make the user comfortable when providing their personal information. If you’re asking for anything sensitive or just somewhat unusual, make sure you include the reason why. It’s also a good idea to let the user know that their personal information–email address and phone number, in particular–won’t be used for malicious purposes.
- Use client-side (i.e., JavaScript) form validation. You absolute must also use server-side validation (for security purposes) but using client-side validation gives the user immediate feedback, without having to send the page to the server.
- Use the fieldset and legend tags to distinguish the form from the rest of the page. I really like these tags and also feel they are underused. Multiple fieldset and legend tags can be used to separate a longer form into its logical components. See the example for what these do to a form.
- Place a submit button at the top and button of a long form. I’m not completely sold on this one but thought I’d mention it as Rob Huddleston advocated it in his presentation. The argument for it is that user’s often go back up to a page or may like having it there if they have to correct a couple of quick things. The argument against it is that it may encourage the user to submit the form prematurely (i.e., before they’ve scrolled down and seen the rest of the form).
- Use the label tag for all inputs. This is an accessibility issue, plus using a label brings up some nice features in the Web browers. For example, most browsers will bring focus to a form element if you click on its label. Labels can be written in a couple of ways, but here’s one recommendation:
<label for="something"> Something </label> <input type="text" id="something" name="something" />
An HTML form should not…
- Request information you have no intention of using or needing. Rob Huddleston pointed out, as a common example, that e-commerce sites don’t really need to ask the credit card type, as the number itself indicates the type.
- Use tables. Tables are pretty outdated by now and should be used sparingly, if at all (CSS should be used instead). Besides the aesthetic and standards issues with tables, they break up forms poorly and can interfere with the use of label tags.
- Contain reset buttons. This is one I learned ten years ago that’s really stuck with me. And yet, lots of forms still have reset buttons. The argument against reset buttons is that the user may inadvertently click it instead of submit, thereby destroying all of their efforts. And how often do users actually need to reset a form? Never? Almost never? More likely a user would either reload the page if they want to start from scratch (which I just don’t think they ever need to do) or go to another page if they decide not to submit the form. Really: best not to use reset buttons at all.
Rob Huddleston also recommended the books Don’t Make Me Think by Steve Krug and Designing with Web Standards
by Jeffrey Zeldman. I haven’t read either yet myself, although both are on my wish lists. I think it’s safe to say that both are considered standard books on the subjects.
I’ll be posting more on HTML forms in this blog, and you may also want to check out my post on poka-yoke. When I get the chance, I’ll try to add some CSS suggestions for making forms look even nicer.
Ouch on the reset button. I have included them in most of my forms that require user information. Although come to think of it I guess it’s really not needed. I can see how users would inadvertently click it instead of the submit button.
I think only one submit button is needed not one at the top also. Most people are used to clicking it when they see it and would click it and just get a error message telling them to fill in the rest of the form.
Well, I’m glad I mentioned it, then. I remember reading about the hazards of the reset button like 8 or 9 years ago but it’s still so common to see them. I agree with you on the two submit buttons. Thanks for your comments!
Good list of tips. Like you, I agree with all of them apart from I’m not at all convinced by the idea of putting the submit button at the top of the form as well. Might work, I just haven’t had the opportunity of testing any forms with this idea to see if it really does work.
(And now a little bit of self-promotion: our book on forms has just been published: “Forms that work: Designing web forms for usabilty”. Steve Krug has been very nice about it and even wrote the foreword for us).
Thanks for the post and good luck with your book!