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.
