Universal Design for Web Applications

Error Handling

Perhaps the most important feature of forms is one that’s completely unspecified in HTML: validation.

It used to be that all problems were handled on the server. HTML and HTTP were just the go-between and didn’t interfere with anything except, for example, the maximum length of a given text field.

Forms are funny things, and people are even funnier. The longer and more complex a form gets, the more likely that something is going to be wrong with what is submitted. It’s missing a required field. A zip code field has too few digits or isn’t relevant (for the 95% of people who don’t have mailing addresses in the U.S.). Or maybe the perfectly valid credit card is perfectly out of credit.

JavaScript has made itself invaluable when it comes to most error conditions; so much so, in fact, that we consider client-side form validation more or less mandatory. What used to be a reasonable delay—the round-trip to the server to find out the results of your form—is now a real inconvenience, especially when your problem could have been fixed immediately.

Communicating error and warning conditions to users is not a standard process—but it is something that you will need to do frequently enough that you should have a plan. Here, too, we need to make sure that the plan includes the most inclusive ways of notifying users of their errors.

Client Side

The first step you should take with your forms validation is to determine what could possibly break. Here are some of the obvious ...