Improving the accessibility of forms
Table of Contents
Online forms are frequently used to allow clients to submit information or requests to institutions. Although forms have a lot of potential to provide interactivity and control to clients, if the forms are designed poorly, they can introduce significant accessibility and usability issues.
This document provides guidance and solutions for designing accessible, usable and Web Standards compliant online forms.
Accessible form design
To ensure online forms are available to all clients and easy to use, accessibility and usability requirements need to be considered at the design phase. The following will help ensure accessible and usable form designs:
- The tabbing order should be logical and intuitive. The focus must move in the correct order when tabbing through the form.
- Forms should only be activated using a submit button.
- Forms should be device independent. The form must be elegant and clear regardless of the input device used.
- Text input boxes should be intuitive and should allow for all reasonable text inputs. The preferred input format should be specified in the
labelbut other input formats should be accepted by the form validation as well.
- Tables should not be used to format forms. CSS should be used instead.
- The clear/reset button should follow the submit button.
- All form controls and buttons should be scalable.
- All form fields should have relevant and programmatically associated labels.
- All text within a form should be programmatically associated with a form field.
- The mandatory and optional fields should be clearly identified using text.
- An acknowledgement of receipt should be provided for any successful form submission.
- Form validation should be performed server-side.
Accessible form controls
What is a form control?
A form control is an element that accepts client input and must be located between
<form></form> elements. Examples of form controls include text boxes, text areas, selects, check boxes, and submit buttons.
Form controls associated with a
<label> element allow the client to select the label in order to affect the associated form control. This is very useful for form controls since it increases the area that can be selected. Increasing the area that can be selected improves accessibility for people who use voice recognition software or have mobility impairments, since selecting a specific area can be difficult for them. Please note that regular buttons (submit, reset, etc.) do not require labels since the labels are already included.
Labels may be placed anywhere within the
<form></form> container but they must be properly positioned in order to associate the labels with the relevant form controls.
To explicitly associate a label with an element, place
for="variable" into the opening label element and
id="variable" into the associated form control where "
variable" is any combination of alphanumeric characters ("-" is also allowed).
Examples of accessible form controls
<strong><label for="srch">Search</label></strong><br />
<input type="text" name="srch" id="srch" size="10" maxlength="80" />
Checkboxes and radio buttons
To associate a question with multiple checkboxes, use both
<legend>I have significant knowledge of:</legend>
<input type="checkbox" name="q1" id="q1" value="c1" /><label for="q1">CSS</label><br />
<input type="checkbox" name="q2" id="q2" value="c2" /><label for="q2">XHTML</label>
<label for="qt">If yes, please outline the problems you encountered.</label><br />
<textarea name="qt" id="qt" rows="5" cols="45"></textarea>
<label for="sprt">Select the sport you wish to play</label><br />
<select name="sprt" id="sprt">
<option value="Hockey">Hockey during the winter months</option>
<option value="Baseball">Baseball during the summer months</option>
<option value="Soccer">Soccer during the summer months</option>
Error messages are used to communicate to the client why a form could not be submitted. If the error messages are not accessible or usable, then clients will have difficulty correcting any invalid form input. The following will help to ensure accessible and usable error messages:
- Error messages should be embedded in the input form. The input form and the error messages should not be on separate pages.
- Client input must be preserved when the error messages are displayed. Clients should not be required to fill out the form again when the form could not be submitted because of client input errors.
- A summary should be provided at the start of the form. The summary should include a text indication of the total number of input errors and should include a list of sequentially numbered error messages. The error messages should be intuitive, preceded by "Error" and linked to the form control where the error occurred.
- Error messages should be included in the labels of the form controls where the errors occurred. The error messages included in the labels should be consistent with the error messages in step 3 with the errors being intuitive, numbered sequentially and preceded by "Error".
- For added value, visually distinguish the error using colour and text formatting.
The following Web Experience Toolkit (WET) features implement this approach:
- Date modified: