Universally Usable Web Forms
•
5 likes•2,629 views
This presentation to the New England Adobe Users Group discusses best practices in designing and building forms that can be used by everyone, and even enjoyed by some.
Recommended
More Related Content
Similar to Universally Usable Web Forms
Similar to Universally Usable Web Forms (20)
Recently uploaded
Recently uploaded (20)
Universally Usable Web Forms
- 1. New England Adobe Users GroupNovember 3, 2009 Universally Usable Web Forms Julie Strothman, M.S. User Experience Researcher & Designer Landmark College Institute for Research and Training
- 2. “My life would be easier…”
- 3. Measuring Usability of Forms Successful completion Abandoned forms Completion time Number of help requests Number of errors Satisfaction after submitting the form Call center: Top issues
- 4. Pop Quiz #1 Some toolbars offer the option of displaying a label below each tool. Why can labeled tools be accessed faster? (Assume the user knows the tool & does not need the label to identify the tool.) From Bruce Tognazinni’sAsk Tog
- 5. Fitts’s Law “The time to acquire a target is a function of the distance to andsize of the target.”
- 6. NEAUG Survey Results: Typical Workflow for Developing Forms Client identifies fields& which are required Layout Test
- 7. Who is filling out the form? What do they need with them? Where might they be? 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?
- 9. Forms are conversations “After all, if software is to be social, then it may as well learn social skills.” -Michael Angeles, konigi.com
- 10. What face-to-face social interaction rules should our forms follow? Only ask what you need to know(Don’t be impertinent!) Be friendly Be patient Don’t speak for the other person(e.g. “Please contact me with more information”)
- 13. Surfacing a Path to Completion: Progress Meters Progress & Location Scope
- 14. Pop Quiz #2: Which is Fastest? Right-Aligned Top-Aligned Left-Aligned Some field Some other field Which of these? An opinion Some field Some other field Which of these? An opinion Some field Some other field Which of these? An opinion This option That option This option That option This option That option
- 15. What?!! Use more vertical space?!!
- 16. Scan Line
- 19. Pop Quiz #3: Higher accuracy rate? Mushrooms Pepperoni Eggplant Mushrooms Pepperoni Eggplant
- 20. Label tags Mushrooms Pepperoni Eggplant <input type=“radio” name=“pizza-toppings” id=“toppings-mushrooms” value=“”> <label for=“toppings-mushrooms”>Mushrooms</label>
- 21. What flavor pizza do you prefer? Mushrooms (no label tag) Pepperoni (has label tag) Eggplant (no label tag) What’s clickable?
- 23. Labels & Reading Order: Acrobat & Flash Must turn on accessibility. When turned on, the software will make best guess. Must review and adjust.
- 24. Labels Inside Inputs Not enough contrast Label goes away when input receives focus No recovery if your attention is diverted No recovery if you fat-finger the field No recovery if you are blind & want to preview the fields
- 25. Captcha
- 28. Error Messages Alert at page top explains in friendly language that something needs fixing. Alert does not rely on color alone. The error message is inside the label tag.
- 29. Confirmation Screen What happens next What was submitted Contact invitation
- 30. Thank You! http://delicious.com/strottrot/neaug Julie Strothman, M.S. User Experience Researcher & Designer Landmark College Institute for Research and Training
Editor's Notes
- In this presentation, we’ll be talking about best practices in designing web forms, and tips for making forms more usable for everyone.
- We’ll start with a video of Kirin Saeed, a screen reader user speaking about how her life would be easier if the web were truly a level playing field. The video is available at: http://www.youtube.com/watch?v=dHBvqwRAduw [I’ve removed the embedded video in order to attach my own narration of the slides.]She says: I would really like to like the web and I have to use the web for work and I have to use the web for everyday usages.But I actually dread it and that’s very sad. I don’t want to dread it; I want to enjoy it. And this particular site that we tried today on YouTube is _so_ much easier. And if Facebook could be easier, and if all these other main sites that I use could be easier, my life would be easier, because that’s what we live with, and more and more the web is going to become part of our lives. More and more the web will be able to be accessed on our mobiles, even for visually impaired people. And I’d like to be able to use that, and not to be afraid of it. And not to feel ashamed. Because the other thing is, 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.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, websites, we’re talking about Kirin, who we just saw. We’re talking about Jessica Cox, the pilot who has no arms who flies a single jet engine using foot controls. ( http://www.youtube.com/watch?v=fK0LvmurKbU&feature=PlayList&p=8F60FB33D1E8165A ) 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. As we look at the variety of choices we make in the forms we create for people to use, I’ll describe the access implications of our choices, including access issues related to mundane constraints, such as being on a mobile device and fat-fingering a form field before reading it, or dealing with sun glare.
- Once we’ve taken care of the first hurdle, making a form available (or accessible), we can evaluate the forms in terms of how effective, efficient, and satisfying they are to use Usability of forms can be measured by such things as 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. We’ll keep these in mind as we look at improving the usability of our forms.
- Pop Quiz #1. Some toolbars offer the option of displaying a label below each tool. Why can labeled tools be accessed faster? (Assume the user knows the tool and does not need the label to identify the tool.) The 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. Do you know what the law that describes this is called?
- 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 consider the implications as you make design choices? The corners and edge of the screen are the fastest areas of the screen to access, because their size is infinite. You can use force to swoosh your pointer up to the menus on the screen edge because it doesn’t require you to stop at a certain point. The screen shot shows an example that bugs me regularly: an email OK/Cancel dialog box. I have to make my pointer stop on that little OK button. The OK/Cancel dialog box requires aiming mid-screen for a small area when I’d rather not have to use the mouse. (I’m not sure why, but even though I’ve got my mac set to tab between all form controls, not just links and inputs, I’m unable to use my tab and enter keys to control OK/Cancel dialog buttons.)
- Before this presentation, I sent a survey to the group to see what kinds of forms you’re working on. People mentioned: Contact, Registration, Sign-up, and data entry—the latter including forms people use every day through which they need go very quickly. I asked about tools people are using: Dreamweaver, Cold Fusion, php, html/css, Joomla, Quark, and PDF. People also spoke of using snippets from previously coded forms, using fieldsets & legends (both for semantic value in grouping items as well as hooks for CSS), and of using Dreamweaver Spry to customize validation & error messages. I asked you about your typical workflow, which was largely to get fields identified by the client, do some layout, and to test to see if it works. Nobody said anything about identifying who will be filling out the form. So what are some things that are helpful to know about how the form will be used?
- What do they need with them? Where might they be? 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’s 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: Is the priority to make it highly efficient or to slow down the form in order to encourage well thought-through answers?
- Forms are conversations. We want them to be pleasant experiences for our customers and community members. We don’t want them to be like an unfriendly checkout-counter experience. http://www.flickr.com/photos/en321/2191752992/
- Our forms are stand-ins for our voice. They are what makes the web two-way. They stand between people and productivity. Forms help us close deals. Michael Angeles said, “After all, if software is to be social, then it may as well learn social skills.” So, what are some face-to-face social skill rules our forms should observe?
- 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. Don’t speak for others. 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. (Nothing gets me into a negative conversation with a website faster than when it pretends to know what I’m thinking. Wait. Talking out loud to your computer is normal behavior, right?)
- Here’s a picture from a gas pump. “Insert Card Fully. Withdraw card quickly.” What feeling do you have when you see 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. Luke Wroblewski, in his excellent book, Web Form Design,says, “Forms suck. We should design accordingly.” [ http://www.rosenfeldmedia.com/books/webforms/ ]
- Consider trying to make your forms a peaceful place to be. Look at this photo of a wooded Vermont lane, or close your eyes. Take a minute to think of someone extremely reassuring. Remember some time they reassured you. Did you think of someone? If not, how about Mister Rogers? Remember when he promised we would never, ever go down the bathtub drain? Our forms could strive to be that reassuring. So think of your reassuring person—that’s going to be your Reassurance Genie. When you create a form, you should 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? The goal of our forms design, well-stated by Wroblewski, is to provide a clear path to completion.
- One way we can provide a clear path to completion on multi-page forms is through the use of progress meters. 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. One way to surface a clear path to completion is to provide a progress meter. Luke Wroblewski’s book, Web Form Design, 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.
- Pop Quiz: Which layout is the fastest (or most efficient) to complete, among the alignments pictured in the slide (with labels right-aligned, labels aligned just above input fields, and left-aligned labels)? Wroblewski cites an eye-tracking study by MatteoPenzo in July 2006 that found top-aligned labels (shown in the center of the slide) to be 10 times faster than left-aligned labels (shown on the right in the slide). [ http://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php ] Why do you think that might be? There is a close association between label and input denoted by their position. (Sufficient spacing between label-input pairs is necessary to achieve the association within a pair.) The fact that the eye can see all fields by moving down in a straight line reassures that the user will not accidentally miss a field. Another benefit is that the labels are scalable: there is more space to add words to the label than in the narrower columns seen in right- and left-aligned label-field layouts. When the labels of right- and left- aligned labels are large, there is quickly awkwardly large and inconsistent spacing between inputs. A common concern about top-aligned fields is that it will use too much vertical space. Why are people concerned about vertical scrolling?
- Some concerns about vertical space include that people will need to scroll to see how long the form is. (True, but I don’t know of evidence that says people mind scrolling once down and up to assess scope. If they are curious about scope, scroll, and have an easy time scanning straight down, they have the satisfaction of an answer to their concern about scope.) What else? The decision maker “wants everything above the fold.” While this is a common desire, it is based on the idea that we can predict the viewport size. Even if we know the most common browser sizes, we can not predict the size to which people will scale their browsers. When we run into such arguments, we can offer to do cheap, low-risk multivariate testing: we can use Google’s Web Optimizer [ http://www.google.com/websiteoptimizer ] to run two different versions of the page and see which is more successful. (For instance, which has a higher ratio of form completion-to-visits.) Another place where vertical screen space may be a problem is desktop applications that are a fixed height. This might be a situation where the designer opts for right-aligned labels. [ Photo credit: http://www.flickr.com/photos/rhinoneal/2411842658/ ]
- This screen shot of a form demonstrates how top-aligned labels can lead the eye down a clear path.
- This is a heat map image from any eye-tracking review of PayPal’s checkout form, showing eye fixations predominantly down a clear scan line. (The image is from http://www.etre.com, used in Wroblewski’s book, and shown here with permission, located at: http://www.flickr.com/photos/rosenfeldmedia/2367261378 .
- This image shows an eye-track from thePenzo label alignment mentioned earlier. Here we see a form with left-aligned labels, as well as eye fixation points spread from label-to-field and back many times. While this and the proceeding image are of different forms (and one is a heat map visualization), we can see that the issue we are addressing in terms of layout is the effort the eyes and brain must make in coordinating labels and inputs. These images support the notion that top-aligned labels require less effort.
- Pop Quiz: Which of these layouts of radio button options has a higher accuracy rate: the group shown left-aligned, or the group displayed in left-to-right fashion? The left-aligned options have a higher accuracy rate. With multiple radio options and less than stellar spacing between radio button-label pairs, it requires more thought to discern which label is associated with a given radio button. This depends a great deal on the spacing used by the designer. In any case, it is more frequent that people select the wrong option when they are listed horizontally rather than vertically.
- Let’s talk about label tags—the HTML tags used in the code behind the form. 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 slide, 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. For more details about how screen readers read labels and form fields, see: http://www.usability.com.au/resources/wcag2/ . Form labels are crucial for accessibility. They are also a huge boon to usability.
- RememberFitts’s Law? Label tags affect how much is clickable on a form. When the label tag is used, the button and the text all become 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. This slide shows the radio buttons surrounded in an html fieldset, with an html legend (“What flavor pizza do you prefer?”). Fieldsets and legends are a wonderful visual way to group related questions and provide a heading or individual question. Screen readers use the legend information, either reading the legend before each item inside the fieldset (as JAWS does), or to let the user know when the group of questions begins and ends (as Window Eyes does).
- As a quality assurance, and accessibility check on all my forms, I use the Web Developer Toolbar’s Form Information page to look at tab order, id’s, and labels. [ http://chrispederick.com/work/web-developer/ ] The tab index is the order in which the form fields will receive focus as someone moves through the form if they are using the tab key on their keyboard. (One might do this if one can not use a mouse, or because it is a faster way to move through the form.) If the tab order is not set explicitly in the HTML, the browser will follow the order of the fields in the code. If you do any floating of form fields, be sure to set the tab index to a logical order in the HTML. The ID and the label, as we have seen are used by screen readers and to make the target area larger. ID’s must always be unique within a single page. Sets of radio buttons and checkboxes will share a common name, but the ID of each option must be unique. As you review the form information, you can review to be sure the tab index is logical, the IDs exist and are unique, and the labels exist. While you may not be coding forms, this is a useful tool for choosing online survey tools or forms plugins for your content management system. If these tools don’t make use of form labels, let the owners know that you can not use their tools until they do!
- Some of you said you are using Flash and Acrobat to create forms. These forms also require attention to labels and reading order. The default setting for Flash is to have accessibility turned off. (Can you believe that?) In both of these tools, the workflow is to create the page elements and then add information to make them accessible. When instructed, each program will make a best guess at form field labels and reading order. In each case, you will invariably need to spend a good deal of time adjusting these settings to make sure everything is included and accurate. Adobe provides information on how to use the accessibility features of their software at: http://www.adobe.com/accessibility
- A common technique these days is to place labels inside input fields. Sometimes the text inside the input is an extra help prompt of what to enter. 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: https://addons.mozilla.org/en-US/firefox/addon/7313 .
- 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. An example of this is available on our interest form: http://www.landmark.edu/institute/professional-development/interest-form.cfm and additional instructions at: http://webaim.org/blog/spam_free_accessible_forms/
- The screen-shot here is a wonderful example of using in-line error-catching and help. This is a technique that catches errors as they are happening so you can provide instant assistance to your user, giving them the sense that they have validated their entry before hitting submit. This is done through the use of javascript. The caution, however, is that Javascript must only ever be used as an enhancement. First ensure that there is a means for error-catching for someone who can not use javascript, then add real-time enhancements through javascript. I find that this is one of the most common areas of accessibility that people decide to skip. Either it is too much work, or they would have to hire someone to do the coding of the server-side error catching.
- 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 they system feedback (such as error messages) is persistently available.
- When error messages appear on the page after form submission, there should be a clear message at the top of the page, informing the person that there is something that needs their attention. The message should not rely only on color. Many people have difficulty distinguishing color, and the color will not be perceived by someone who is blind. While most people will not actually read the alert at the top of the page, it should include instructions for finding the specific errors in the page. Specific error messages should be displayed as part of the label tag, making explicit the association of the error message and the relevant input field for people listening to a screen reader.
- Confirmation screens are an important part of the conversation between the form and the user. They should 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. This information should be available. It’s very reassuring to the person submitting the information. It provides a means for people 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.
- Thank you! While this presentation was by no means comprehensive, I hope it provokes your thinking about the effects your design decisions have. You can find me on twitter: @strottrot and at my blog: http://www.strottrot.com .