Usable and Accessible Form Validation and Error Recovery
Advantages of server-side validation and error recovery include:
- The form can be completed and submitted without interruption from validation alerts, errors, or warnings.
- Functionality does not require that scripting be enabled or supported on the web browser.
- More secure - the validation mechanisms cannot be easily bypassed or modified.
Advantages of client-side validation and error recovery:
- Validation can occur as the form elements are completed and before the form data is submitted to the server.
- Functionality does not require server-side scripting.
The Web Content Accessibility Guidelines 1.0 state that you should, "ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported." Older browsers and new portable technologies may not support scripting; and there are many reasons why users may have scripting disabled. As such, developers should not require client-side scripting in order for the web form to be accurately completed and submitted. However, web developers can utilize the benefits of both server-side and client-side validation and error recovery to ensure that their forms are completed in a usable and accessible manner. To ensure the validity of the information that is submitted, server-side processing should typically be the final mechanism for ensuring that the forms are completed accurately and completely.
Building Usable Forms
As a developer, the first step to ensuring that your forms are completed correctly is to make the form user friendly and accessible. This can be accomplished by:
- providing all necessary instructions and cues.
- associating form elements with a text label by using the label element.
- logically grouping form elements using fieldset and legend.
- providing a logical reading and navigation order.
- ensuring that the form can be completed and submitted using the keyboard.
- conducting user testing to ensure that the form elements, labels, and functionality are understandable and usable.
If your form requires that certain elements be completed or selected, you should indicate this to the user in a usable, accessible, and apparent manner. These instructions should typically be located adjacent to and within the label of the required form element. Because screen reader users may navigate from form element to form element rather than having the screen reader read through the form linearly, placing this important information within the label allows the screen reader to read it when the form element receives focus. The label should be adequately descriptive and also be visually apparent.
<label for="firstname">First Name
<span style="color:red">(required)</span></label><br />
<input type="text" name="firstname" id="firstname" />
Use of color or other styling (bold, italicized, etc.) alone to identify required form elements will not be sufficient for users who may not see color or styling due to the technology used (web-enabled cell phones, for example), web browser settings, or disability. While common practice, the use of the asterisk to identify required form fields also may not be sufficiently descriptive or informative to some users. If information entered into form elements must be formatted a specific way, adequate instructions must be provided within the form element's label. In many cases, developers can simplify their forms by not requiring a specific formatting. If a precise format is required for submission to a database, for example, scripting can often be used to reformat the user-entered information to match your required format, thus removing this burden from the user.
As an example, telephone numbers in the U.S. may be formatted as 555.555.5555, (555)555-5555, 555-555-5555, 555 555 5555, 1-555-555-5555, or any combination of these. Rather than requiring the user to conform to a specific format, you could use scripting to restructure any of the previous formats to that which you desire for your web application. You should also ensure that your form validation mechanism does not fail because of leading or trailing white space within text boxes or text areas. It may not be apparent to the user that an extra space is present. The white space can be easily removed using server-side processing.
Hiding Form Labels
There are some cases where developers may not desire to have form labels appear visually within their forms. This is common when using complex forms within tables when table headers identify the function or purpose of multiple form elements within a specific row or column. By viewing table headers, it may be visually apparent what information should be entered into the form elements. It may be cumbersome to visually display repeated form labels throughout the complex form. This is complicated by the fact that one form label can only be associated with one form element. However, if the
<label> element is not present, screen readers may not identify the purpose of the form element.
There are methods of hiding form labels (and other elements) in a web page so they do not appear visually, but are still accessed by screen readers. However, care must always be taken when visually hiding elements from a web page. You should ask the question as to why the information is not useful or necessary visually, but is important to the screen reader user. You must also be aware that visually hiding form labels removes some functionality from the page - users can click on the form labels to immediately access the form element with which the label is associated. This can be especially helpful for users with some types of motor disabilities.
Form validation itself does not typically pose accessibility issues as it is usually performed behind the scenes. However, the method for invoking the form validation mechanism must be accessible. This means that if you are using client-side validation, the validation and submission process must be available to both the mouse and keyboard. Because you cannot typically ensure that the user's browser supports scripting, the form must also submit to a real URI if scripting is not available. You should avoid forms that rely on script functions or event handlers for form processing:
<form action="#" onsubmit="validateform()">
Instead, use a true URI action for the form. You can still invoke client-side validation, if available.
<form action="submit.php" onsubmit="return validateform()">
This would allow you to first process the form validation using client-side scripting, if supported and enabled. The validateform() function would validate the form and provide necessary feedback and error recovery mechanisms. If the validateform() function returns true (i.e., there are no validation errors detected) or if scripting is not enabled, then the form information would be submitted to the submit.php page for server-side validation and processing. As an alternative, DOM (Document Object Model) scripting can be used to validate the form without using script code within the body of the page.
If either client-side or server-side validation detects errors in the form, then there is a 3-step process for ensuring usable and accessible error recovery:
- Alert the user to the presence of the error in an apparent and accessible manner.
- Allow the user to easily access the form elements that need to be modified.
- Allow resubmission and revalidation of the form.
You can also allow the user to directly enter text responses using script prompts.
The error message can also be written to the web page itself. When client-side scripting is available, you can write the message to the page before the form is submitted. With server-side scripting, you typically regenerate the form page to include the original form and the appropriate message. Feedback pages that display only the error message and ask the user to hit the Back button to fix them can be difficult. They require that the user remember all of the errors reported and then go to the previous page and find where those errors have occurred. It is typically best to regenerate the page so that the form looks and functions similarly to the original form that was submitted. When doing so, be sure that form elements that were previously completed correctly are unaltered - if a user has deselected the checkbox to join your mailing list, do not change this option when regenerating the page.
Feedback messages typically appear immediately before the beginning of the form itself. 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. Because focus can only be set to one place in the page at a time, multiple errors should typically be displayed together, rather than at varying locations throughout the page. It is also helpful to inform the user as to the number of errors that were found.
<a href="#firstname">enter your first name
Here's how the feedback message might be displayed within the page.
Such an approach allows the user to easily access the missing or incorrect form element by simply activating a link. Once the form errors have been remedied, the form can be resubmitted and revalidated.
In all cases, careful user testing can usually alert you to difficulties or problems in your form usability, validation, and error recovery mechanisms. While this article only addresses a few of the many variations that can be used to ensure form usability and validation and accessible, user-friendly error recovery, the following general principles should be applied:
- Build forms that are easy to use and intuitive. Provide all necessary instructions, cues, and prompts.
- Ensure the forms are keyboard accessible.
- Associate form
<label>elements with form controls.
- Use fieldsets and legends to group related form elements.
- Include necessary instructions within form
<label>elements (e.g., required or specially formatted elements)
- Alert the user of any validation errors in an apparent and accessible manner. Provide informative feedback messages.
- Allow the user to easily access the form elements that need to be modified.
- Allow resubmission and revalidation of the form information.