Validating web forms
Posted August 18th, 2009 by David HamillIn this post I’ll give you a few tips about validating web forms. Your form validation can make the difference between a user completing your form or abandoning it altogether.
It’s not a complete list of advice, so feel free to add your own tips in the comments section.
Tell them something’s wrong
You need to begin by making it obvious that there has been a problem with the form. Often forms just reload with a small message beside the appropriate form field. On a large form this approach isn’t helpful.
If the message is far enough down the page, the user will need to scroll down in order to see it. So they end up staring at the top of the page wondering what has happened.
Don’t blame the user
Don’t accuse your users of having made an error. They may well have done so, but it could just as easily have been your fault.
Telling users they have made an error is like a waiter in an expensive restaurant tutting at the mess, whilst crumbing down your table. It doesn’t help and it doesn’t improve the experience.
Recovering from validation problems
Rather than pointing out the problems with what they did, tell the user what they need to do in order to proceed. For example ‘You didn’t enter a phone number’ should be ‘Please provide your phone number’. This approach is more helpful and focusses on recovering from the issues.
The example above shows a form that is inconsistent in its approach. In most cases it tells the user that they didn’t do something. However sometimes it offers the resolution to the problem instead.
Whilst not perfect, the example above still gives the user a good explanation of the problems.
A worse example is when forms speak to you like a robot. “Email Address is a mandatory field” is not the best way to tell someone that they need to enter an email address. Unfortunately, ‘explanations’ like this are very common.
Don’t use alert boxes
Javascript alert boxes aren’t good for delivering validation messages on forms. The image below illustrates the issue. In order to proceed, the user must click OK. When they do so, the message disappears. So they need to remember the problem or re-submit the form to read the message again.
When a form with JavaScript alert validation encounters multiple issues the experience gets worse. It either lists all of the issues on one alert (that then disappears). Or it pops up with a new alert after the previous issue has been resolved. Both of these approaches have the potential to infuriate people.
Don’t validate optional fields
If the form field is optional, then it’s often best not to add validation.
When the field is optional, you can presumably live without the information. If you can live without the information, then it’s not a good idea to be pedantic about its accuracy. Validating an optional field just increases the potential for complications to arise.
Having said this, there will be occasions when an optional field must be validated. So let’s use a couple of examples.
Phone number
If you’re giving someone the option of providing their phone number, don’t bother validating the field. The number is useful but not essential, so it won’t be a big problem if they type it incorrectly.
Choosing a user name
Let’s say your user is given the option to substitute their real name with a user name. This field would be optional, but you’ll probably need to validate it. You’d need to check that it follows whatever rules you’d created for user names. You’d also need to check that the user name isn’t already in use.
Validation and disabled users
When providing your validation, give a thought to people who perhaps don’t use a mouse or can’t see the page itself. Form validation is a major stumbling block for visually impaired and blind users. This is because some web designers rely solely on visual cues when providing it.
These visual cues are helpful but you can’t rely on visibility alone. The example below shows a good approach that could be made better for keyboard users.
Visually, this seems like a fairly straightforward and helpful approach to form validation. But what about those using a screen reader to read this page?
The descriptions will potentially be quite distant from the form fields in question (in this example I kept them close in order to fit into the picture). A screen reader user has to navigate down the page using their keyboard and find the form field. They may then need to go back up the page to read the next problem.
This can create a lot of problems for the screen reader user.
How you should do it
OK, I’ve spent enough time complaining about what not to do. I’ll now explain my favoured approach to form validation. This approach helps users of all abilities to quickly diagnose and recover from validation problems.
1. List the problems at the top of the page
Without apportioning blame, explain (in red text) at the top of the page that there was a problem. Then list all of the things the user needs to do before he can proceed.
Make each list item a link to the appropriate form field. This will allow screen reader users to skip straight to the field they need.
2. Repeat the instruction in front of the form field
Put a red-bordered box around the form field and label concerned (or highlight it in some other way) and repeat the advice. Be sure to put the advice before the field (in your HTML) so that a screen reader will read the advice before arriving at the field. You can then use CSS to position it elsewhere if necessary.
What’s so good about this approach?
This approach makes it obvious that there are problems with the form. The user knows how many problems there are and what they need to do to fix them. It also provides features that make it easy for users of all abilities to quickly skip straight to the problem questions.
What about in-line validation?
I haven’t covered in-line validation on this post. I hope to write a second post helping you prevent errors on forms. This post should cover in-line validation.
What do you think?
Join the discussion by posting a comment below. If you’ve enjoyed this post, you might also enjoy:
26 Responses to “Validating web forms”
August 18th, 2009 at 8:42 am
OK, I need to hold my hands up here and admit that my own validation is very poor. I am looking into it and will remove this comment when it is sorted. Apologies in the meantime.
August 18th, 2009 at 11:30 am
Thanks for sharing, David. I totally agree that one of the biggest sources of frustration on the web are forms that won’t submit because of errors, especially when the errors messages are difficult to decipher. That’s a great idea to link the error message to the form field. That benefits people on screenreaders but everyone else also.
David has covered this, but everyone should double check that all of the form errors are listed together, not in a succession as each one is resolved by the user.
Another QA tip for everyone: try submitting your form with completely empty values and otherwise try to break it. Problems encountered by real people won’t always be reported to you and they’ll go elsewhere…
August 18th, 2009 at 10:30 pm
My Pet peeve is when they ask for a phone number. 1] I don’t have a land line. I don’t need it. Yet I haven’t seen a single form that says ‘any one phone number between landline and mobile is good enough for us’. 2] Formatting. It makes me cry. I believe you have talked about it elsewhere on your site. Country code? Zero after that? Can I put spaces in the number? Gah! 3] When I don’t know how many steps the form is going to take. Is this a one page form? Will I get what I asked for in the next page? will you send it to my email address or give it right here for download. I guess suspense makes life spicy.
Please write more David. Your posts are thoughtful.
@geetanjalid
August 19th, 2009 at 6:21 am
I like the ideas on how to communicate form validation errors to the user, that seems like a far better way to help people understand and encourage them to fix their form entries. Language is so important to good usability.
On inline validation, I presume you mean JavaScript. These days there’s nothing to stop you using exactly the same communication techniques in JS since you can add content to areas of the page on the fly. The biggest hurdle is keeping any client-side validation in check with server-side validation.
August 20th, 2009 at 2:02 pm
Very useful points David. Forms are always an issue on sites and these points will help to make them better for visitors and site owners. You don’t happen to know of any scripts that cover all these features, do you? I don’t do the programming myself. Thanks.
August 20th, 2009 at 2:06 pm
Hi Ann, No, I’m afraid I don’t. I’ll let you know if I find anything though.
August 20th, 2009 at 2:24 pm
Excellent post. For people like Ann who want to implement these suggestions in code, I’d recommend the free “Uni-Form” http://sprawsm.com/uni-form/. Based on jquery, it allows you to implement all of David’s suggestions, even if you have just a basic knowledge of CSS and HTML. We use it on the Userfocus site to validate our training delegate signups and it works a treat.
August 20th, 2009 at 2:27 pm
Thanks David. A fountain of knowledge as ever. I’ll take a look at that.
August 21st, 2009 at 2:02 pm
[...] Validating web forms http://www.goodusability.co.uk/2009/08/form-validation/ [...]
August 22nd, 2009 at 9:28 pm
Great post, and great point about the language of validation problems. The simple fact that they’re usually in makes the user jump anyway – no need to blame them as well!
August 23rd, 2009 at 10:45 am
Excellent stuff. You should add the term “best practices” into the title.
August 24th, 2009 at 12:59 pm
Hello David,
I would like to add a point to your article. You state “Without apportioning blame, explain (in red text) at the top of the page that there was a problem. Then list all of the things the user needs to do before he can proceed.”
This solution would imho be even better if you add an icon or something to increase the attention: red text alone isn’t a very visible cue for colorblind people.
August 24th, 2009 at 1:13 pm
Hi Ivo, thanks for this. I wondered about this point myself. Unfortunately I’ve never tested form validation with a user who has red/green colour blindness. I think a border around the introductory text should be sufficient. I’m not convinced about the need for an icon.
August 25th, 2009 at 7:03 am
Geeta – couldn’t agree more about rigid/confusing formatting rules! Sometimes coders can be quite petty and lazy about formatting, and a little extra code to make things a bit more flexible and responsive can help people along without the need for an error.
For example, if someone enters 1/9/09 into a date field instead of 01/09/2009, is there really need to throw an error? What about 1-9-09? A few lines of cleaning code can fix and accept this with limited risk of assuming the wrong date.
Or if there are spaces in the person’s credit card number, surely it’s better to silently strip those out and say ‘thanks for your money’ rather than ‘i’m not going to sell anything to you until you remove the spaces from your credit card number’.
Cheers David, great post!
August 25th, 2009 at 8:14 am
Hi Charlie, thanks for commenting. I’ll be discussing exactly this in my follow up post about avoiding validation errors.
August 25th, 2009 at 10:07 pm
In this graphic, http://www.goodusability.co.uk/wp-content/uploads/2009/08/mywaytop1.png, you list all the fields that didn’t pass validation in the form of links so that the user can go straight to each field. Which is great for a sighted person. But after someone using a screen reader corrects the first field, how do they get quickly get back to the list of errors in order to click on the second link? Especially if this form is at the bottom of a page full of links. BTW, this isn’t hypothetical. I’m actually wrestling with this issue right now!
August 25th, 2009 at 10:08 pm
Hi Timothy, it’s actually pretty easy for people who use screen readers such as Jaws to skip back to the top of the page (if you use good mark-up). In fact if you observe someone using a screen reader, it’s like they’re within navigating the page. They can do this as long as you use the correct mark-up for headings. Modern screen readers have keys for skipping between header tags.
If your validation messages appear directly after a heading 1 for instance, a Jaws user can just navigate through the headings in order to get back there.
The other option is that they can tab through the remaining fields until they get to the next field that has a validation error.
August 25th, 2009 at 10:12 pm
Also you wrote:
“Don’t use alert boxes
Javascript alert boxes aren’t good for delivering validation messages on forms. The image below illustrates the issue. In order to proceed, the user must click OK. When they do so, the message disappears. So they need to remember the problem or re-submit the form to read the message again.”
If after clicking “ok”, focus is immediately moved to the field in error, the user will ‘usually’ be able to handle the problem. The key is not to make the user go searching for the field.
August 25th, 2009 at 10:22 pm
Hi Timothy. But the description of the problem has disappeared. On a very short form form with perhaps 1 or 2 fields, you will be able to get away with an alert. But on a form with numerous fields you rely on the user remembering each of the problems. How does your approach work when there are multiple issues? Either you need to list all of the problems on one alert (and then only focus on the first field) or generate a new alert after the previous issue has been resolved. Both of these approaches are demanding a lot from the user’s short reserve of patience.
August 26th, 2009 at 2:22 am
Speaking of usability, as someone who comments on a lot of blog posts, I highly recommend the numbering of comments. It makes it much easier to be clear about which comment is being referenced in a later comment.
I agree that the examples you’ve given are better solutions to validation than “one dialog box at a time” if you have a standard form.
However my problem is that I don’t have a standard form. The form I’m enhancing for screen readers makes extensive use of progressive disclosure.
The point of using progressive disclosure is to keep from asking the user stupid questions. If they tell you they have no prior experience, it’s lame to ask them where they worked.
It works in a similar fashion for education and criminal history.
For example, if a user answers everything but “do/will you have the normal education required for this”, they’d only have one field that still needs answering at THAT MOMENT. But as soon as they answer “Yes”, they get 3 new questions. If they answer “No”, they get 1 new question.
About 30,000 people have successfully filled out this form in the past 6 years. But reconfiguring this for screen readers has been a challenge. I now have the screen reader advancing to the correct field based on their answer and that was really tough. But coming up with a decent validation scheme for a form utilizing progressive disclosure being filled out by users utilizing screen readers has been even more of a challenge.
August 26th, 2009 at 8:05 am
Hi Timothy, I’ve responded to the email you sent me with these questions. I’d also suggest that you don’t use the number of people filling it in as a success measure. For all you know 150,000 people might have tried to fill it in.
Thanks for the tip on the comments. Until now my current approach has worked OK. I guess I haven’t had someone ask 2 questions before I’ve had a chance to answer the 1st one. Keep it up though, it’s all very interesting. I’ll look into the comments thing.
Until then, I’ve messed about with the comment time in order to put it in the right order.
August 26th, 2009 at 7:54 pm
First, here’s a great example of a site where the numbering of comments is vital:
http://www.edbrill.com/ebrill/edbrill.nsf/dx/erik-brooks-i-am-sick-and-tired-of-hearing-about-8.5.1?opendocument&comments#anc1
Next: “For all you know 150,000 people might have tried to fill it in.”
Actually I do know. Given that the people who fill out this form have no place else to go to get a license in our jurisdiction, I seriously doubt they are going elsewhere over difficulties with a form.
What they will do is pick up the phone and call when they have ANY questions or encounter ANY difficulty. And they call a lot. But they never have questions or complaints about filling out this form. Our other application, yes, but not this one. And when the phone rings with website issues, it rolls downhill and I’m at the bottom
That stated, we’re always looking for ways to improve. And improving accessibility is what’s needed most.
Thanks for your feedback. I have made some changes as a result.
August 30th, 2009 at 12:23 pm
[...] Good Usability » Validating web forms [...]
September 2nd, 2009 at 10:16 am
Thank you for very helpful advice. I use my own php form handler. I built in validation to prevent spammers hijacking my form, but I would prefer instant advice about an incorrect entry alongside the field for maximum accessibilty. I am unhappy with the fact that my validation only occurs when the user clicks the Submit button. Do you know of a source of PHP code for inline validation. I do not wish to use javascript.
September 2nd, 2009 at 1:15 pm
Sorry, code snippets aren’t really my thing. Be careful about how much you rely on in-line validation. It can be pretty disruptive if used too much or innapropriately.
September 5th, 2009 at 2:01 am
Luke Wrobleski just published an excellent article on inline validation. Pairing it with your article, I can offer great advice to the programmers I work with. Thanks to you both!
Comment on this article