Validating web formsPosted August 18th, 2009 by David Hamill
In 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
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.
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: