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 forms are completed and before the form data is submitted to the server.
- Functionality does not require server-side scripting.
Some users may disable scripting. As such, developers should not require client-side scripting in order for the web form to be accurately completed and submitted. Additionally, any client-side validation or information can readily be modified or disabled. 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.
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 controls with a text label by using the label element.
- associating groups of checkboxes and radio buttons using fieldset and legend.
- providing a logical reading and navigation order.
- ensuring that the form can be completed and submitted using the keyboard.
- testing that the form controls, labels, and functionality are understandable and usable.
If your form requires that certain controls 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 control. Because screen reader users may navigate from form control to form control 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 control 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" />
aria-required attribute can also be used to identify required fields to screen reader users, especially if the label text does not indicate this or if color-alone or an asterisk are used to identify the required fields.
If information entered into forms must be formatted a specific way, adequate instructions must be provided within the form control's label or other associated content (such as with
aria-describedby). In many cases, developers can simplify their forms by not requiring a specific formatting. If a precise format (such as for telephone numbers) is required for entry into a database, for example, scripting can often be used to reformat the user-entered information to match the required format, thus removing this burden from the user.
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 controls within a specific row or column. By viewing table headers, it may be visually apparent what information should be entered into the form control. It may be cumbersome to visually display repeated form labels throughout the complex form. This is complicated by the fact that one
label element can only be associated with one form control. However, if the
<label> element is not present, screen readers may not identify the purpose of the form control.
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. 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 or activate the form control with which the label is associated. This can be especially helpful for users with some types of motor disabilities. Read more about visually hiding form labels.
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 URL if scripting is not available. You should avoid forms that rely solely on script functions or event handlers, such as
<form action="#" onsubmit="validateform()"> for form processing. Instead, use a true URL action value for the form. You can still invoke client-side validation, and it would be processed first if scripting is enabled -
<form action="submit.php" onsubmit="return validateform()">.
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 controls that need to be modified.
- Allow resubmission and revalidation of the form.
There are three primary ways in which these requirements can be met. We will describe them as:
- Error alert, then focus
- Errors on top
- Inline errors
No one approach is best for accessibility, but there might be an optimal approach based on the content, layout, and complexity of the forms they are applied to.
Error alert, then focus
You could also allow the user to directly enter text responses using script prompts.
The advantage to the "Alert, then focus" approach is that users are informed of errors immediately and can then easily resolve the issue directly. The primary disadvantage is that only one error is indicated and addressed at a time.
Errors on top
The error message can also be written to the web page itself. When client-side scripting is available, you can write the error 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 so that previously completed correctly are unaltered.
The error message should clearly describe the errors that are present and, optimally, include cues or instructions for resolving them. For example, "Course number is not formatted correctly" is not as helpful as "Course number must be a 3 digit number". It is also helpful to inform the user as to the number of errors that were detected.
Once the user has been presented with the error message, you must then provide a mechanism to quickly give them access to the form control that must be remedied. You can provide a link within the error message that will set focus to the appropriate form control. While this can be done using client-side scripting, it is typically easier (and safer) to simply provide a link that will set focus to the form control (as identified by its unique id and/or name).
The advantage of the "Errors on top" approach is that all errors are presented together. The disadvantage is that if there are multiple errors, it can be difficult for the user to remember, find, and address all of them.
Another approach is to display the error messages within the form in the context of the form control that needs attention. This approach requires visually distinctive error messages so focus is drawn immediately to them. The error messages must be associated to their respective controls (via labeling or perhaps
aria-describedby. It may be helpful to set focus to the first control that needs attention.
The advantage to the "Inline errors" approach is that the errors appear in context with their respective controls. The disadvantage is that the user must visually scan or navigate through the form to discover the invalid controls and their respective error messages. This can take some time.
Regardless of the mechanism used to identify and recover from form errors,
aria-invalid="true" should generally be set on each invalid form control. This attribute causes screen readers to identify the control as being "invalid" or in need of attention.
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 associate groups of checkboxes and radio buttons.
- Include necessary instructions within form
<label>elements (e.g., required or specially formatted controls)
- 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 controls that need to be modified.
- Allow resubmission and revalidation of the form information.