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 ...
Get Universal Design for Web Applications now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.