Web Development

An introduction to form validation methods

Ryan Boudreaux introduces the basic methods and approaches to implementing form validation on websites.
As most of you already know, forms are a great way to gather information from your visitors and allow them to submit information to your web server(s) for processing to your website. Typically this includes a database connection to serve, process, and create records to store the information. Forms also allow your customers to interact with your website, for example, by searching for specific information, or by submitting comments to a specified department or email address. Frequently there are times when you will want to ensure that customers don't leave specific form fields blank, or you will want to limit a field to a certain type of input such as characters, numbers, email address, zip code, phone number, or a list of pre-set options from a pull down menu.

This article is part one of a multiple part series on exploring different form validation usage methods, error messages, feedback techniques, and approaches for website form validation implementations.

In a perfect world your web visitors will enter the correct and necessary information and finish the task successfully. However, in the real world people often make mistakes or abuse the process, and this is where form validation makes its appearance. The ultimate end result is to ensure that the visitors provide the proper and correctly formatted information to complete the form submission.

Server-side validation scripts do not rely on or fret with JavaScript support in the user's web browser; consequently, they are unaffected by the presence or absence of JavaScript support in the user's web browser. With server-side validation, information is sent to the server and validated using one of many server-side languages. If the validation fails, the response message is then sent back to the client, and the page that contains the web form is refreshed and a feedback message is displayed. This is a more secure method and works even if JavaScript is turned off in the browser and it is not easily bypassed by users with malevolent intent. The downside with server-side validation is that users will have to fill in the information without getting a response, only until they click the submit button, and this typically results in a slower overall response time for the user experience.

One exception to typical server-side validation is the use of Ajax calls to the server utilizing jQuery; as the user types in the information, it provides immediate form validation feedback. Using Ajax in conjunction with client-side validation, it can preemptively validate forms using the same client-side rules upon form submittal.

Client-side validation using JavaScript provides an overall better end-user experience since the user input can be validated as it's typed, sending immediate feedback response with a failed confirmation. However, one drawback to client-side validation is that some visitors have JavaScript support disabled in their browser either intentionally or unknowingly. Such users can circumvent JavaScript validation routines and submit a form regardless of whether it satisfies the validation rules.

In order to prevent "garbage" form submissions coming in from visitors, web application developers typically will complement client-side JavaScript validation with server-side validation scripts. Most web applications today utilize both client-side validation with JavaScript and server-side validation, for example, ColdFusion and Perl/CGI validation routines to detect problems with user-entered form data and thus prevent the submission of improper data.

There are several types of validation that you can perform, and these typically fall into one of three categories including, required information, correct format, and confirmation.

The first set of information that should be validated is the required information, and this is typically indicated either with an asterisk (*) or a "required" statement adjacent to the field or declared prior to the form. Unless all fields are required, such an indication should be made to give the visitors proper direction for filling in the form fields.

In the case for universal design and access, the required data entry fields should be clearly and consistently distinguished from optional data entry fields. The classified standard should include the following:

  • Provide an asterisk (*) in front of the label for all required fields, and include a statement that precedes the beginning of the data entry form, for example, "A field with an asterisk (*) before it is a required field."
  • Provide the word "required" in front of or below the label for each required field. In addition, a statement indicating the required fields should be provided at the beginning of the data entry form. For example, "All required fields are indicated with the word "required" along with the label.
  • Separate the optional and required fields when appropriate and practical. All groupings should be labeled accordingly "Required" or "Optional" to assist the end user.
In complying with Section 508 (Web Compliance Framework, Dept. of Health and Human Services), using color or bold for emphasis of required fields is not enough to distinguish them from optional fields. Colorblind users or those who utilize screen readers will not distinguish between required or optional data entry fields based on color or bold indications. The example in Figure A shows how required fields are indicated with an asterisk (*).

Figure A

Correct format validates to ensure that URLs, phone numbers, email addresses, numbers, passwords, and other information is entered in the acceptable syntax configuration. While it is tempting to limit the format and syntax for specific types of data, at times it is good practice to permit a variety of formats allowing the application to interpret the data, therefore utilizing a forgiving user input design pattern. In the example shown in Figure B from iStockphoto.com the sign-up form validates the email address and the password, providing an error message and suggestions for correcting the entries with immediate feedback before submitting.

Figure B

Confirmation fields ensure that users confirm the data entered with two fields provided for the same information, for example passwords and email addresses typically require a double entry to confirm correctness. Typically these duplicate fields are placed directly next to one another and are clearly marked so that the user knows their purpose up front. When the two entries match ,the form is submitted successfully; if not, then an error message should indicate that the two entries are dissimilar. A good example of confirming fields is displayed in Figure C from Angie's List.

Figure C

Most web authoring tools typically have powerful built-in functions which can help in creating validation fields within a form that ensure that the fields are properly completed by the online users. For example, in Dreamweaver's Validate Form Behavior, it uses JavaScript to enforce the rules that you specify for a particular web document form. When a website user attempts to submit a form containing blank fields and/or has entered any inappropriate data, they will receive a pop-up window displaying an error message indicating the specific problem, resulting in the cancellation or temporary halt of the form submittal until the problem has been corrected. Once the user has made the corrections and the validation rule(s) that you established have been satisfied using the Validation Behavior, then the form will be successfully submitted.

Most built-in validation tools including Dreamweaver's Validate Form Behavior can only validate the contents of text fields and cannot check that the correct radio buttons, checkboxes, drop-down lists, etc. are selected by the user. What you can do is use the Validate Form Behavior to ensure that text fields meet the following criteria and conditions:

  • Contain numbers only. You can reject a form submission if a text field contains anything other than digits.
  • Has a numeric value within a range. You can reject a form submission if the number in a text field is outside of the specified range.
  • Contain an email address. However, it is important to note that validation typically only checks for the presence of an @ symbol in the email address, and does not check to see if it's a properly constructed email address such as user.name@domain_name.com
  • Contains something. You can reject a form submission if no information is present in the text field.

In the next segment, I will demonstrate creating a simple form that will perform validation of several different text fields within a web document page using Dreamweaver in the examples.

Future segments will dive deeper into form validation coding methods, as well as review validation feedback, validation upon submit, real-time validation, adding helpful hints, dynamic tips, masking and reformatting user inputs, and adding captcha code to ensure human interface. I'll then put together a list of form validation resources. Let me know if there are particular form validation questions that you have in the discussion area below.

About

Ryan has performed in a broad range of technology support roles for electric-generation utilities, including nuclear power plants, and for the telecommunications industry. He has worked in web development for the restaurant industry and the Federal g...

2 comments
l.will
l.will

A few things that irritate me when filling in web forms: 1. Text boxes that are too small to contain more than a few lines, like this one, and which either prevent you from seeing a complete response or make you scroll. 2. Text boxes which limit the number of characters, especially when they don't tell you the limit until you try to submit the form, coming back with an error such as "Text exceeds 500 characters". 3. Forms which make it impossible for you to keep a copy of what you have submitted, because of scrolling boxes. If this is essential, the form should indicate that a full confirmation copy of your submission will be displayed in a printable form after you have submitted it, and/or sent to you by email. 4. Fields that assume specific local formats for data such as telephone numbers and postal codes, especially those that reject formatted telephone numbers such as "+44 20 8123 4567" or "(020) 8123 4567" because they contain non-numeric characters or spaces. 5. Ambiguous date formats when you don't know whether dd/mm/yy or mm/dd/yy are required. Can we encourage people to use the ISO date format yyyy-mm-dd, which at least allows sensible sorting? 6. Confirmation fields that ask you to enter information twice. I always use cut and paste to fill in the second of these, which negates their purpose. 7. Forms that use unusual field names so that my browser's AutoFill function cannot be used.

eCubeH
eCubeH

Surprised there is no mention of XForms. XForms + CSS does everything for us! We have complex web apps deployed using the Mozilla XForms plugin, though soon we will experiment with the Ubiquity library and XSLTForms too. Schemas & Validations; Highlighting Required or Readonly fields or Invalid entries; Error messages; Conditional submits; Repeat structures; etc. Nice article though. Looking forward to all the tips and the coming sections.....