I heartily recommend Luke Wroblewski’s Web Form Design (May, 2008) for people who create web forms and for those who hire others to create them. The book is structured in three parts: form structure, form elements, and form interaction, and includes a plethora of real-world examples. Whether you’re a novice or expert, walking through Wroblewski’s overview of forms-related issues will provoke your thinking about design choices and their impact. Luke is Chief Design Architect at Yahoo! and blogs at Functioning Form.
Below are some of my thoughts and recommendations in response to the book.
Deepen your understanding of other people’s experiences
Who are we to not bother to ensure the resources we create are universally usable? As you are thinking about making better web forms, deepen your understanding of how design choices affect people with disabilities.
Peter Wallack wrote an accessibility piece for Web Form Design, offering a list of the “most important” accessibility requirements to consider. He reminds us that it is up to website designers to ensure their forms are accessible to millions of people with physical and cognitive disabilities.
Wallack urges us above all, “Test your page with your intended users, including those who have disabilities.” There is broad diversity among people with disabilities and their approaches to using technology. Shawn Lawton Henry offers suggestions for recruiting participants with disabilities in her book Just Ask: Integrating Accessibility Throughout Design.
Check out this YouTube accessibility playlist of people talking about their disabilities, demonstrating using a variety of assistive technologies, and speaking of their experience using the internet:
“…I feel often ashamed because I can’t use it as well and I’m not that old; I’m quite young… And it becomes a battle and it should be a level playing field. The web should have created a level playing field for visually impaired people and disabled people as a whole, and what I feel sometimes the web does is it actually blocks people out and it isolates you more.”
Kirin Saeed, a screen reader user discussing her experience using the web (link: youtube video).
As web designers and developers, we all make things for people to use. If you are not working on making your resources accessible, you are making a choice to block some people out. This can cost you and your clients or your organization money. And it causes great frustration for real people. When we talk about accessible, or universally usable forms, we’re talking about Kirin, (above). We’re talking about Jessica Cox, the pilot who has no arms who flies a single jet engine using foot controls. She recently flew a plane from Arizona to Wisconsin, but she might not be able to fill out your web form because you didn’t bother to make it accessible to alternative input devices. We’re talking about friends with muscular sclerosis who must use extreme effort to control a mouse, with minimal success. We’re talking about brilliant co-workers who have non-verbal learning disabilities and will spend inordinate amounts of time trying to divine what unfamiliar abbreviations, idiomatic expressions, and unclear icons are meant to convey.
In addition to listening to people talk about their experiences, learn to browse your pages with alternative methods. Try listening to your web pages with the web-based screen reader WebAnywhere. (Better still, install the free NVDA screen reader (Windows only) and learn how to test with NVDA.) Become proficient in keyboard navigating the web. I would bet that if you spend any time moving around a web page with only your tab key, you’ll quickly get a sense of how important it is to maintain (or enhance) the unformatted dotted line box decoration of links when they have focus. As you deepen your understanding, you’re likely to create fewer problems that need fixing.
Why are people filling out your form?
Recently, before giving a presentation I surveyed attendees about their typical workflow. Generally, people described getting fields identified by the client, doing some layout, and testing to ensure it works. Nobody said anything about identifying who will be filling out the form. In Web Form Design, Caroline Jarrett (author of Forms that Work) encourages us to think about people and relationships, and to balance user and business needs.
So what are some things that are helpful to know about how the form will be used? What do people need with them? Where might they be when filling out the form? If they’re on a mobile device, do their needs change? What will they need to do with the transaction in a month? How often will individuals use the form? How will the data be retrieved? What will it be used for? It’s often a big mind-shift for clients to think in terms of the people coming to their forms. It is far more common to be thinking of the data entry you will do in order to complete your own tasks, than to consider the experience of the people filling in the forms. Addressing recovery issues, such as what happens if a person is interrupted or needs information they don’t have with them at the moment will make your form more usable. In the last few weeks, I have twice purchased things over the internet on my phone. Neither website sent me an email copy of my receipt. If the designers had considered that I might be purchasing something for my business or that I would be on a mobile device, I would be able to supply a receipt to my accounts payable office. Another important consideration is the frequency with which people will use a form: Wroblewski points out the tradeoff between making forms highly efficient versus encouraging well thought-through answers.
Web Form Design includes an overview of measuring how effective, efficient, and satisfying forms are to use, by assessing things like successful completion, abandoned forms, completion time, number of help requests, number of errors, satisfaction after submitting the form, and common issues in call center logs. Throughout the book, Wroblewski points to results of various usability studies, in support of various recommendations for layout of forms, alignment of labels, use of progress meters, etc.
Social Rules for Forms
Wroblewski underscores the notion that forms are conversations, and need to be approachable and respectful. Our forms are stand-ins for our voice. They are what makes the web two-way. Wroblewski notes that forms stand between people and productivity and they help us close deals. Michael Angeles said, “After all, if software is to be social, then it may as well learn social skills.”
What face-to-face social interaction rules should our forms follow? Only ask what you need to know. (No impertinent questions! If you and I had just met, I wouldn’t ask you for your street address unless you asked me to send you something.) Be friendly.
Avoid speaking for your site visitors. If forms are a conversations, the questions are the website’s side of the conversation, and the form inputs are the other side. Phrase your questions accordingly. Many forms, instead of asking questions, speak in the voice of the user. For example, field labels such as: “My Address.” “Sign me up for a trial now.” “Please contact me with more information.” Speaking in the voice of the user removes the opportunity to have a conversation with the person. You also run the risk of the person reacting negatively to something being said for them. (I’ll report back if I get a chance to test this with people.)
Build User Confidence
Here’s a picture from a gas pump. “Insert Card Fully. Withdraw card quickly.” What response do you have when you encounter this? What’s going to happen if I fail to remove the card quickly enough? Perhaps not everyone gets panicky when they encounter these signs. Nevertheless, we don’t want to create that unsure feeling of “What if I mess up?” for people filling out our web forms. Our designs should reassure the user that they have control over the form in as many ways as possible.
Wroblewski suggests form should have reduced noise and contrast. He suggests calling to mind soothing rooms and a friendly smile. I’ll go a step further and suggest you think of Mister Rogers. Remember when he promised we would never, ever go down the bathtub drain? Our forms could strive to be that reassuring. Mister Rogers, or someone you know, can act as your Reassurance Genie. When you create a form, do a ‘reassurance genie’ test as part of quality assurance. Call your reassurance genie to mind. What would they think of your error messages? Of your confirmation screen?
Provide a clear path to completion
The goal of our forms design, well-stated by Wroblewski, is to provide a clear path to completion. The decision to do a single page versus multiple pages is not clear-cut. The drawback of multiple pages on an unfamiliar site is a lack of trust that people will be able to go back and forth between pages if needed without losing data. We must do everything we can to facilitate recovery and reassure users that they will be able to change their entries. When a form is rather long, and there are logical breaks, one might decide to do a paginated form, either with links such as ‘Continue’ and ‘Go Back’ or as a series of tabs. Progress meters indicate stages of multi-page forms. Wroblewski describes the essential aspects of successful progress meters: They should explain the scope of the form (that is, how many steps or pages), they should show your progress and location (that is, where are you along the path to completion), and they should accurately reflect the actual steps. It is critical that people can go back and forth through pages without losing their data, and with the ability to make changes.
Form Labels and Fitts
Web Form Design includes a chapter on labels (the text associated with a form field). Wroblewski compares various layouts of labels and their fields, answering questions such as which layout results in the speediest completion, which requires the least effort, and which scales best to accommodate growing text. Luke covers some of this in his slides Best Practices for Form Design on slideshare.net.
WFD does not touch on Fitts’s Law and coding form labels and input fields such that they are explicitly associated with each other in the code behind the page.
Fitts’s Law states, “The time to acquire a target is a function of the distance to and size of the target.” The further away a target is, the larger it needs to be to maintain access speed. Bigger things are easier to hit. This seems obvious as I say it, but do you take this into account when you create a form? Think about toolbar icons as an example. Some toolbars offer the option of displaying a label below each tool. Labeled tools can be accessed faster because the label becomes part of the target. The target is therefore bigger. Bigger targets, all else being equal, can always be accessed faster. When labels are not used, the tool icons crowd together, and are easier to miss. When targets are large, you don’t have to slow down so as not to overshoot the target.
Label tags are the HTML tags used in the code behind the form. Label tags affect how much is clickable on a form. When the label tag is used, the button and the text all become clickable. (In the example on the left, the green areas are clickable. Making the target area much larger will improve completion time (efficiency) and make your forms easier to use. Labels provide this benefit for checkboxes, text boxes, and other form fields.
Form labels are crucial for accessibility. Using a label explicitly (that is, using the ‘for’ attribute to refer to a unique ‘id’) tells a screen reader which label is associated with which input field. While the input field has focus (that is, while it is selected), the browser will recognize the connection between the label and the input. In the case shown in the image, a screen reader will speak, “Mushrooms Radio Button not checked. One of three.” Any time this radio button has focus, it will indicate it is the mushrooms option and how many other options there are. If the code does not explicitly make the association of the label and the input, the screen reader will read “Radio button.” The screen reader will then say the text “Mushrooms” and the user will have to tab backwards in the form to select the radio button, never being sure they’ve actually selected the radio button they intended to select. Roger Hudson offers details about how screen readers read labels and form fields.
Avoid placing labels inside inputs
Wroblewski talks about some of the pitfalls of placing labels inside inputs, a technique used to reduce impact on screen real estate. Sometimes the text inside the input is a secondary prompt of what to enter in addition to an actual label (as in the example on the left). Other times it is the only information indicating what the field is for. Often labels inside inputs are light gray to distinguish them from real answers. Frequently the light gray provides little contrast to make it readable by anyone with reading difficulties or trouble distinguishing color. The common behavior of the text inside the input is that it goes away when the input receives focus and the person enters any information. What if you click on the label, hit the spacebar, and the phone rings. When you come back, will you know what the field was for? Will you need to refresh and lose the other data you had already entered? A person who is blind may tab through all of the fields to see if they’re willing to fill out the form. For any fields where they start typing, when they go back through the form to fully fill it out, the labels will be gone. What if the person entered something unreadable, for example their fingers were shifted on their keyboard and they hadn’t noticed? How will you know what the question was? What if you’re on a touch device and you fat-finger the field before you read it? Labels are generally put inside inputs in order to create a cleaner-looking field, or reduce the vertical length of the form. However, the usability trade off is not worth the gain. Regarding color contrast, I recommend Gez Lemon’s Firefox Extension, the Colour Contrast Analyser. It provides a report of all of the color contrast combinations in a page, indicating which pass contrast validation tests and which do not.
Captcha stands for “Completely Automated Public Turing test to tell Computers and Humans Apart.” This screen shot is from Google’s account creation page. It shows a very difficult-to-read captcha word that must be typed in the field below. Sometimes, these at least offer the ability to request a new word, but not here. One could refresh the page repeatedly until getting a legible ‘word,’ but you would have to re-enter the information you had already filled in. If you have reading or vision difficulties, you can click on the wheelchair. What do you think happens if you click on the wheelchair? It plays audio of the letters. I don’t know about you, but a wheelchair doesn’t make me think of audio (or reading difficulty for that matter.) The audio is not helpful if I’m in a situation where I need my device to be silent. As a spam-reducing alternative to captcha, consider using CSS to hide a form field with an empty value. You can then use server-side form validation to check to see if a spam bot has unwittingly filled in this field. You can see an example of this looking at the code on an interest form. WebAIM offers instructions on spam-free accessible forms.
Dismissable error messages trip people up
Beware of dismissable error messages, like the one depicted in this screen shot. This is an example where you submit a form and a box appears with information about errors that need to be fixed. It may be worded in a very friendly matter. While most modern screen readers can read such an alert message, many people struggle with short-term memory issues. In order to fix the form errors, you must dismiss the alert message, losing your instructions about what needs fixing. This type of alert is the default for things like the Adobe Cold Fusion <cfform> tag, which is designed to reduce the effort of people creating web forms. People will be far more able to recover from their errors when the system feedback (such as error messages) is persistently available. Web Form Design includes many examples of error and success messages, as well as validation treatments before form submission.
Don’t forget the confirmation screen
Confirmation screens are an important part of the conversation between the form and the user. Too often forms say thank you and don’t bother with any detail. Include information about what will happen next with regard to the transaction. (Only offer a promise you can keep!) Show the person the information they submitted. It is very reassuring to the person submitting the information and it provides a means for them to check their submission. Provide your contact information: how can they get in touch if they made an error. If they can not contact you directly, give information about how they can adjust their submission. You can also use this opportunity to keep them on your site by providing links that may be useful based on the form they just submitted, or as Wroblewski puts it: encourage more progress.