Form Validation and Error Recovery
by WebAIM
Introduction
Form validation is the process of testing to ensure that end users enter necessary
and properly formatted information into web forms. Error recovery is the process
of guiding the user through fixing missing or improper information as detected
by form validation. There are several methods of performing form validation
and error recovery. These methods can typically be categorized as being, 1)
server-side - the form information is submitted and analyzed by the web server
through some scripting language (such as PHP, JSP, Perl, etc.) with necessary
feedback messages being written to a new, dynamically generated web page, or
2) client-side - form validation and error recovery mechanisms are performed
within the web client or browser using a client scripting language (such as
JavaScript or VBScript). There are advantages to each method.
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"
/>
Displays as:
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
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="javascript:validateform()"> or <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.
Error Recovery
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.
The first step is to inform the user that there is an error. This error message
should be visible, informative, and accessed directly. One method is to use
a JavaScript alert box to inform the user of the error.
ndicating that required information was not submitted.
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.
The error message should either be the first item within the new page or focus
should be set directly to it. This allows screen reader and keyboard users to
immediately access the error message without having to find it amongst the rest
of the page contents. The message should also be visually apparent. Focus can
be set to the message with client-side scripting using JavaScript focus() or
similar, or the server-generated page can include an anchor name in the URI
(e.g., http://myserver.com/form.php#errormessage) which will set focus directly
to a named anchor or element id located at the beginning of the feedback message.
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.
Once the user has been presented with the error message, you must then provide
a mechanism to quickly give them access to the form element that must be remedied.
When using JavaScript alerts, focus can be set to the form element using the
client-side scripting language when the prompt is dismissed. When the feedback
message is written to the page, you can provide a link within the error message
that will set focus to the appropriate form element. 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 element (as identified by its unique
id and/or name).
Please <a href="#firstname">enter your first name</a>.
Such an approach allows the user to easily access the missing or incorrect
form element by simply clicking a link. Once the form errors have been remedied,
the form can be resubmitted and revalidated.
Summary
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)
- Do not rely on JavaScript alone for form submission, validation, and error
recovery.
- 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.
posted on Jun 13, 2007
Article
Topics
Google