There are four main requirements for coding an accessible form:

The label element

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 for and id values match.

<label for="FirstName">First name:</label>
<input name="fn" type="text" id="FirstName">
<label for="SecondName">Second name:</label>
<input name="sn" type="text" id="SecondName">

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.

View more information on accessible form controls»

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.

        <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"/>

Form layout

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.

View more information on logical form layout»

Keyboard accessibility

When using javascript on a web form, make sure that the widget can be operated using the keyboard only. For example, when coding a select menu, do not use the javascript 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.

  • Pre-populate fields for Javascript users only.
  • Don’t use pre-populated input values as a substitute for HTML <label> elements.
  • Use Javascript to clear the pre-populated text when the the text field receives focus. Don’t use onClick to trigger this event; use onFocus. Then use onBlur to restore the default value if users leave the field without entering new text.

View more information on creating accessible forms»

back to top