In The Three Models of Web Form Validation, I stated that validation plays a dual role of protecting your data and site from bad data, as well as a guide to your users’ goal of submitting the form in as painless and quick a manner as possible. The focus of both that and this article, is the latter role. Today, we’re going to look at message positioning, content, and visual cues.
Message Positioning
How you position validation feedback can have a significant impact on form usability, especially for longer forms. Here are some of the best locations along with the advantage(s) of each:
- Top of the page:
This is a validation response either placed at the top of the page, or directly above the form. This works especially well for screen-readers, because it will be one of the first elements they read when the page reloads. -
Inline:
Validation placed in close proximity to the input where an error has occurred is considered to be “inline”. This can work equally well for real-time validation and for longer web forms. -
Bottom of the Page:
This is a validation response either placed at the bottom of the page, or directly below the form. This location works best for Ajax validation, where the page is not refreshed. Since the Submit button is likely to be situated below the form, the user will not have to scroll to see the error messages.
A hybrid approach can also work if you don’t mind doing some extra work to make your users’ experience better. For instance, if only one error has occurred, it may be more helpful to display the message and set focus to a point immediately preceding the incorrect form element, rather than at the top or bottom of the page. Multiple errors are usually easier to deal with when displayed together, rather than at varying locations throughout the page, because in the latter case, it’s too easy to skip over some. Finally, consider telling the user the number of errors that were found.
Validation Message Content
A validation message should mention what input field the error relates to.
When referring to an input, you should always use the label of that input as this is how users will identify the input referred to in the message. For this reason, it’s a good practice to store labels in a variable to reuse in validation messages.
A validation message should give some indication how the error may be fixed.
If the error is complex, such as a password formatting issue (on a password reset, not a login form!), it’s always best to suggest possible solutions. For instance, if a telephone number can’t contain alphabetic characters, then include that in the message, rather than provide a generic “Invalid character” message. It’s especially helpful in the case of formatting to provide examples. In fact, placing samples in the label itself is best if possible:
Phone Number (555) 555-5555:
The exception to this rule is ID and password combinations, where the rule of thumb is to be as non-specific as possible.
If you are refreshing the page after a server submit, error messages should be set directly to the first item. Either use JavaScript or include an anchor name in the URI (e.g., http://myserver.com/form.php#errormessage), if it is not the first item within the new page. Here’s a message that includes a link to the field in question:
Please enter your first name. Other form content
Try it out:
Other
form
content
The message should be visually apparent. Color is one way to distinguish error messages from other page content, but be careful to use colors that standout against the background and won’t obscure the message for those who suffer from color blindness. Here’s a page that shows some of the most problematic color combinations.
Using Icons and Visual Cues
Icons are another way of communicating the overall content of message before a user has a chance to read any textual response (i.e., information, warning, error). Icons are a great way of displaying inline validation where screen real estate is at a minimum, as well as reinforce colors. Simple icons tend to work best, for example a checkmark for success, or a red cross (X) for an error.
There are many other style elements that you can apply to validation responses, such as borders, font weights, and backgrounds. Be sure to consider the positioning of your errors, how you are displaying the errors, and the general style of your website. Although any response messages should stand out from surrounding elements in order to be recognizable, there is no reason that they cannot be complimentary to the rest of the website look & feel.
Conclusion
Whether or not you employ Ajax calls, use client-side validation, or simply submit data to the server for review, there is no excuse for having poor validation mechanisms and messages in place. All that separates a user-friendly site from a major turn-off is the following of a few simple guidelines. Your workload can be even lighter, thanks to the dozens of JavaScript form validation libraries freely available for use. In the next article, I’ll present a few good ones for your consideration.