Creating Accessible Forms
Screen Reader Form Accessibility

Article Contents

  1. Page 1: General Form Accessibility
  2. Page 2: Screen Reader Form Accessibility
    1. Provide a Logical Form Layout
    2. Using Form Labels Appropriately
      1. Create labels for form elements using the <label> element
      2. Group related form elements using the <fieldset> element
    3. Sample Code
  3. Page 3: Accessible Form Controls
  4. Page 4: Using Dreamweaver and FrontPage to Create Accessible Forms

Provide a Logical Form Layout

One of the most common ways of navigating through a form is using the Tab key. A person fills in one field, hits the Tab key, fills in the next field, and so on, until the end of the form is reached. For visual users, this is an easy thing, because the labels are placed in such a way that they appear to be linked to their corresponding controls. For a blind person using a screen reader, however, visual layout is not going to be of much help. There has to be some way of linking the label with its control in the markup. Let me give an example to demonstrate the possible confusion that can occur with a form that is poorly marked-up and poorly organized.

[skip over confusing table]

First Name
Email
Home Phone
Middle Initial
Computer type
Work Phone
Last Name
Mac PC
Country
Internet speed 28.8 56k T1

Visually, this table makes at least some sense (even if it is a bit confusing). For the most part, a person with sight can figure out that the First Name label goes with the control beneath it, and that the Email label goes with the control to the right of it. What happens when we remove the colors and strip it of its formatting, though? A screen reader will read the above table in this order: The visual nature of the following table will limit its usefulness to users of screen readers. The point that is being illustrated is that screen readers start with the top row, reading the entire content of each cell from left to right across each column in the row, until the end of the table is reached. Select this link to skip over the table.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

Even though a screen reader will not render the colors that have been shown, they were left in for comparison purposes. If you compare the reading order to the visual order in the table above it, you can see that the labels and the form elements do not match up very well. The person using the screen reader is likely to become very confused, and may fill in the form incorrectly, typing information in the wrong places.

Let's hear what the form sounds like to a screen reader:

Using Form Labels Appropriately

There are two things that we can do to the previous table to fix it:

  1. Put the labels adjacent to their controls
  2. Use HTML markup to associate the controls explicitly with their labels

One way to fix the accessibility problems of the above table would be to reduce the table to two columns, placing the labels directly to the left of the form elements, then adding in the appropriate HTML elements (see the HTML markup of this form at the bottom of this page):
Computer Type


Internet Speed


Create labels for form elements using the <label> element

When a screen reader user is navigating through form elements on a web page, the screen reader software will identify the type of form element that is currently selected and will provide them means to complete, select, de-select, or submit that form element. However, when navigating through the form, there is often no indication as to what information is desired with the particular form item. For instance, if the user navigates to a text box using the Tab key, there may be no indication as to whether the text box is where they should submit their name, address, phone number, a message, or any number of other things.

This can be solved by associating form labels to form items on the page. The label should almost always be located adjacent to the form item itself. When a screen reader accesses a form item that has a <label> element associated with it, it will read the text within the <label> element and indicate the type of form item it is (e.g., "First Name. Text box" or "Age. Check box"). Labels are needed for all form elements, except for buttons; the screen reader reads the text that is on the button (e.g., "Submit button").

Group related form elements using the <fieldset> element

When you have several associated form elements, they can be grouped together by something called a fieldset. Each fieldset should have a legend. The legend is the text that describes the associated group of form items. In the above example, fieldsets are defined for Computer Type and Internet Speed.

The fieldset typically generates a visual border in the web browser that surrounds the contents of the fieldset. The fieldset, in this example, is defined by the border that surrounds the three checkboxes and their adjacent labels. The legends of these fieldsets are the words Computer Type and Internet Speed. In this example, the label for the first checkbox in the Internet Speed fieldset is 28.8. The fieldset is important, because without it, if the screen reader were to access the checkbox, it would read something like, "Twenty eight point eight. Not checked". While this is valuable, it gives no description of what the data is for. Is 28.8 referring to Internet speed, age, height, IQ, or something else? With the fieldset in place, the screen reader would read something like, "Internet speed: Twenty eight point eight. Not checked." Fieldsets should be used when there are groups of check boxes or radio buttons. They can also be used for other form items that are associated.

Even if the screen reader is incapable of reading the label, fieldset, and legend elements that were added above (as is the case with some older screen readers), the improved table above is organized in such a way as to make it possible to figure out which labels go with which controls.

Let's hear what the form sounds like now, with the improvements that we made:

Sample Code

To get a better idea of what went on behind the scenes look at the HTML markup of the form below. Notice the label, id, fieldset, and legend elements.

[skip over code]

<form method="post" action="">
<table width="50%" border="0" cellspacing="0" cellpadding="4">
<tr bgcolor="#CCCCCC">
<td>
<p align="right"><label for="fname">First Name</label></p>
</td>
<td>
<input id="fname" type="text" name="text33" size="12">
</td>
</tr>
<tr>
<td>
<p align="right"><label for="lname">Last Name</label></p>
</td>
<td>
<input id="lname" type="text" name="text34" size="12">
</td>
</tr>
<tr>
<td>
<p align="right"><label for="mi">Middle Initial</label></p>
</td>
<td>
<input id="mi" type="text" name="text35" size="1">
</td>
</tr>
<tr>
<td>
<p align="right"><label for="hphone">Home Phone</label></p>
</td>
<td>
<input id="hphone" type="text" name="text36" size="12">
</td>
</tr>
<tr>
<td>
<p align="right"><label for="wphone">Work Phone</label></p>
</td>
<td>
<input id="wphone" type="text" name="text37" size="12">
</td>
</tr>
<tr bgcolor="#FFCCFF">
<td>
<p align="right"><label for="country">Country</label></p>
</td>
<td>
<input id="country" type="text" name="text38" size="12">
</td>
</tr>
<tr bgcolor="#CCCCFF">
<td>
<fieldset>
<legend>Computer Type</legend> <br />
<input id="mac" type="radio" name="radiobutton3" value="radiobutton">
<label for="mac">Mac </label><br />
<input id="pc" type="radio" name="radiobutton3" value="radiobutton">
<label for="pc">PC</label><br />
<input id="linux" type="radio" name="radiobutton3" value="radiobutton">
<label for="linux">Linux</label><br />
</fieldset></td>
<td>
<fieldset>
<legend>Internet Speed </legend> <br />
<input id="288" type="radio" name="radiobutton4" value="radiobutton">
<label for="288"> 28.8 </label><br />
<input id="56k" type="radio" name="radiobutton4" value="radiobutton">
<label for="56k">56k </label><br />
<input id="t1" type="radio" name="radiobutton4" value="radiobutton">
<label for="t1">T1</label>
</fieldset>
</td>
</tr>
</table>
</form>

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University