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.

Measuring Usability

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 Alternatives

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 they 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.

11/2009 narrated presentation: Universally Usable Web Forms

What is OpenID and Why Use It?

OpenID reduces the number of logins a person needs to create and remember, making it possible to use a single ID to authenticate to many online services. The ID is any address that you can prove belongs to you (i.e. you can log in to it) and that is enabled with OpenID-related tags. OpenID describes itself as an “open, decentralized, free framework for user-centric digital identity.”

Getting and Choosing an OpenID

To log in using OpenID, you need an OpenID-enabled URI: a web address that is associated with you and which you can authenticate to. The following are each URIs I can use as my ID on any OpenID enabled site:

1. http://www.flickr.com/strottrot/
2. http://www.claimid.com/strottrot
3. http://www.strottrot.com

You may already have access to OpenID: Yahoo, flickr, blogger, technorati, and aol are just a few OpenID providers (IdP’s) who have made it possible for their users to use their account URI as an OpenID. If you don’t have an account with an OpenID provider, verisign, claimID.com and others provide IDs. You can also use your own blog or other URI as your OpenID.

Choosing your OpenID URI provokes questions about how you manage and connect your various online identities. The OpenID you use often becomes a live link to your OpenID URI, such as when you post a comment on a blog. When I use my meme online, do I want people to link to my blog, flickr, linkedin, facebook, del.icio.us, technorati, or somewhere else? Do I bring these presences together? Jeffrey Zeldman mused about online identity spread in his busy April 22nd post, The Vanishing Personal Site.

Using an OpenID

A growing number of sites invite authentication via OpenID login, such as technorati, 37signals, wikiHow, drupal, and many blogs.

When you log in with OpenID, the site you are trying to log in to puts a request to your ID’s URI. A couple of tags at your OpenID URI redirect the request to the IdP to verify that you own the URI. The IdP has you log in to your page to prove you are the owner and then confirms to the requesting site that you are the owner of that URI. Simon Willison offers a screencast of OpenID in action.

Control, Privacy, and Security

There are a few control-related issues with OpenID, the first being the longevity of your relationship with a 3rd party. If my ID is tied to a site where I maintain an identity (e.g. flickr, technorati), and eventually that site goes away or I stop affiliating with the site, I will have links and logins I created in the past tied to those accounts. Similarly, the site itself might fold. For increased control, you might choose delegation: using a URI you own, such as your domain, in combination with an OpenID provider. In this scenario your URI can be ‘permanent’ but you can switch IdP’s (OpenID providers) anytime. (Check out Sam Ruby’s tutorial on setting up delegation.)

A second control issue is security-related. Once you are logged in to a site through OpenID, your IdP manages login requests from that site, giving security control decisions to the IdP. This is risky in terms of both phishing and CSRF (cross-site request forgery) attacks.

Regarding privacy, your IdP processes all of your OpenID login requests, gathering a great deal of information about your activities. Whom do you trust with that information? Trust not only in that you believe they are not evil, but that their servers can not be compromised? You can use multiple IdP’s to spread out the knowledge about you to mitigate the tracking potential of a single IdP, but at some point this defeats OpenID’s promise of reduced sign-on.

In terms of security, there’s a plethora of discussion out there. (Check out Eugene and Vlad Tsyrklevitch’s great paper and the idcorner.org post on OpenID security.) In short, when you log in somewhere with OpenID, you are taken, ostensibly, to your IdP’s authentication page, but phishing could be at work, tricking you into providing login information to a 3rd party’s site. Why not just stick with a password manager on your computer?

Have you changed your passwords lately?

Is Trivial-Use-Only a Valid Recommendation?

I’ve seen the recommendation to use OpenID only for trivial uses, such as blog logins. If it gets hacked and someone can be you using your OpenID, then they can still be you on other OpenID-accepting sites. This recommendation is only useful if risking your identity associated with web posts is acceptable to you and only while the sites accepting OpenIDs remain trivial in nature (or until the phishing and other security issues are solved). If you decide to go with a trivial-use-only approach, I recommend the following: Create a free id at claimID or OpenID and delegate to your own URI for increased control. When you create your ID, use a strong password you only use for that ID, so that if it gets hacked, you haven’t given away the store.

User Experience

Entering a URI (web address) for a username breaks login conventions: it is something to which people will need to become accustomed. The first time you authenticate with OpenID, it likely requires more steps than creating an account on the site requiring you to log in. (This is especially the case if you are not currently logged in to your IdP.) On mobile devices OpenID is unwieldy. Not only do you have to key in an entire URI, you’re far less likely to be surfing on a handheld and thus logged in to your IdP, so you’ll also need to log in to your IdP after keying in that long URI.

OpenID and Accessibility

Accessible implementation of OpenID requires more than a label and id on a login form. People who are new to OpenID need some explanation about what it is and that they may be sent briefly to their id provider’s website for authentication. OpenID login should be visually and semantically separated from username and password fields. Yesterday Clayton Lewis got me thinking about the wonderful accessibility opportunities in the realm of OpenID. Perhaps your OpenID URI will store information about your preferred minimum font size or a link to your alternate style sheet, making it easier to switch from browser to browser and computer to computer without needing to repeatedly enter these settings. What accessibility problems or promises do you see with OpenID?

My primary audience is people with Learning Disabilities (often using a screen reader). Skip links are useful for this audience for the same reasons they are useful to keyboard navigators and screen reader users who are blind.

I think ’skip to content’ is generally preferable:

• ‘Skip to Content’ is more specific. A specific destination is named. ‘Skip navigation’ usually really means ’skip a bunch of stuff’ (the header image alt tag and text, the top navigation, the search bar, the links in the left column).
• ‘Navigation’ is usually not meant literally. As reason #1 suggests, you may be skipping over a bunch of stuff in addition to links and breadcrumbs. People with Learning Disabilities, who often interpret things quite literally, as well as less-frequent web surfers, will have to think about what ‘navigation’ means and what it is they will be skipping.

I suspect that forcing left-column navigation to appear after the content in the code is confusing for sighted screen-reader users. (In this country, when we look at a web page, we expect it to read left-to-right and top-to-bottom.) I’m hoping to test this out in our Usability Lab.

I did not realize that content-less anchor tags are “ignored by JAWS and several other browsers and screenreaders .” In this article, Communis mentions the difficulty in deciding what to put in the anchor (or rather put the anchor around, like some header). I looked at the W3C’s XHTML 1.0 specs and found a few interesting things:

1. the name attribute for the a element is deprecated in XHTML 1.0
2. as long ago as HTML 4.0, you could link to an <id>. This is great because it means my ‘Skip to Content’ link with an href of #content will take users to the div wrapper with the id of content (or it could be assigned to an h2 or some other appropriate element). This removes the need for an extra anchor tag, and for extra styling to remove the link styling which would otherwise be applied to that extra anchor tag.