There are four main requirements for coding an accessible form:
<label>tag to describe form fields and controls to screen reader users.
<legend>tags when necessary to group form elements together.
- Keep form labels close to their associated controls.
- Make sure the form is operable using just the keyboard.
- Take special care when pre-populating text-entry fields
Associate all data entry fields with labels so that screen reader users can easily tell what they are supposed to enter in the field. Screen readers have two different modes, forms (interactive) mode and browsing (virtual cursor) mode. Without labels, a screen reader user will have to repeatedly switch between forms mode and browsing mode in order to navigate the form, which is tedious. A properly labeled form allows the screen reader user to successfully operate the form in forms mode. The following example illustrates this technique. Note that the
id values match.
<p> <label for="FirstName">First name:</label> <input name="fn" type="text" id="FirstName"> </input></label> </p> <p> <label for="SecondName">Second name:</label> <input name="sn" type="text" id="SecondName"> </input> </p>
There are instances when a screen reader user needs to have a label, but a sighted doesn't need a prompt, e.g., the three fields of a Social Security number. In such cases you can position the text “off-page” with CSS to insert labels so the screen reader knows to enter 3 digits, 2 digits, and 4 digits for the Social Security number fields. These prompts would be intrusive to sighted users, so we have ensured that they will not be displayed by the browser.
Fieldsets and legends
Fieldsets are used to group form elements together and are announced by screen readers. Fieldsets are also displayed with a border, which is helpful for all users, and especially for those with cognitive disabilities. Fieldsets should be accompanied by a
<legend> tag, which describes the association. The following is an example form with a fieldset, legend, and labels.
<fieldset> <legend>Your account information</legend> <label for="first">First Name</label> <input id="first" type="text" name="first"/> <label for="last">Surname</label> <input id="last" type="text" name="last"/> <label for="accountnumber">Account Number</label> <input id="accountnumber" type="text" name="accountnumber"/> </fieldset>
Tables are typically used to create the form layout. There is nothing inherently inaccessible about tables, as long as you are aware that the visual layout of a table does not necessarily translate well to the reading order used by a screen reader. Keep the table as simple as possible. A screen reader parses a table left to right and top to bottom. If the labels and controls are in different table cells, make sure that the label’s cell directly precedes the associated form control or text-entry cell.
onChange event to automatically direct users to a new page. This effectively limits the menu choices to one item, because when the keyboard user attempts to investigate the next menu item with the arrow key,
onChange is set to
true and the first choice is always activated. The accessible alternative would be to code a select list with a form button to effect the change.
Pre-populating text fields
When you pre-populate a text input field, special care must be taken to ensure that the form field is accessible. A complete explanation of the points below can be found in Terrill Thompson’s blog post on the subject.
- Don’t use pre-populated input values as a substitute for HTML
onClickto trigger this event; use
onFocus. Then use
onBlurto restore the default value if users leave the field without entering new text.