ARCHIVED - Making forms accessible
This information has been archived because it is outdated and no longer relevant.
Archived Content
Information identified as archived on the Web is for reference, research or recordkeeping purposes. It has not been altered or updated after the date of archiving. Web pages that are archived on the Web are not subject to the Government of Canada Web Standards. As per the Communications Policy of the Government of Canada, you can request alternate formats by contacting us.
Table of Contents
1.0 Introduction
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 Common Look and Feel (CLF) compliant online forms.
2.0 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.
An example of an accessible form is available in section 5.0 (Example of an accessible form).
3.0 Accessible form controls
3.1 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.
"W3C Checkpoint 10.2 - form controls" and " W3C Checkpoint 12.4 - control labels" require that each form control be associated with a <label> element (with the exception of "hidden" elements). This allows 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).
To test whether the label is working correctly, simply select the label. If the result is the same as selecting the associated form element, then the label is working correctly.
Listed below are some examples of accessible form elements. Note that the "for" and "id" attributes must contain the same text for the labels to work correctly. An example of a form with accessible form controls is available in section 5.0 (Example of an accessible form).
3.2 Examples of accessible form controls
3.2.1 Text box
<strong><label for="srch">Search</label></strong><br />
<input type="text" name="srch" id="srch" size="10" maxlength="80" />
3.2.2 Checkboxes and radio buttons
To associate a question with multiple checkboxes, it is necessary to use both <fieldset> and <legend>.
<fieldset>
<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>
</fieldset>
3.2.3 Text area
<label for="qt">If yes, please outline the problems you encountered.</label><br />
<textarea name="qt" id="qt" rows="5" cols="45"></textarea>
3.2.4 Select
There are accessibility issues for clients using a keyboard when the multiple selection option is enabled (multiple="multiple"). It is impossible in some browsers to select more than one option when the options are not next to one another. Consequently, the multiple selection option (multiple="multiple") must not be used.
<label for="sprt">Select the sport you wish to play</label><br />
<select name="sprt" id="sprt">
<option value=""></option>
<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>
</select>
4.0 Error messages
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.
An example of an accessible form with accessible error messages is available in section 5.0 (Example of an accessible form).