Using the <label> Element

Consider the following field, and the prompt that precedes it:

<div>
  Last name: 
  <input type="text" name="last_name" id="last_name">
</div>

The prompt “Last name” precedes the input field, but its relationship to the field is not explicitly defined. Therefore, some screen readers will simply announce this as an “edit” field, but will not prompt the user to enter “Last name” into that field. Other screen readers will guess at the label, and in this example will probably guess accurately. However, as forms grow in complexity, screen readers that guess at labels are more likely to guess incorrectly, which means users are more likely to complete the form incorrectly.

The following code has been corrected. “Last name” is now defined as a label, and is explicitly associated with the form field because the label’s for attribute and the input’s id attribute share the same value.

<div>
  <label for="last_name">Last name:</label> 
  <input type="text" name="last_name" id="last_name">
</div>

Using <fieldset> and <legend> Elements

For groups of related fields such as radio buttons and checkboxes, each form field must have a label as described in the previous section. However, that prompt alone can be meaningless if the user doesn’t know the question. The technique for addressing this problem is to group these elements together using a <fieldset> element, then use a <legend> element to markup the question, as in the following example:

<fieldset>
 <legend>What is your favorite color?</legend>
 <div>
 <input type="radio" name="color" value="Red" id="color_red">
 <label for="color_red">Red</label>
 </div>
 <div>
     <input type="radio" name="color" value="Green" id="color_green">
     <label for="color_green">Green</label>
   </div>
   <div>
     <input type="radio" name="color" value="Blue" id="color_blue">
     <label for="color_blue">Blue</label>
 </div>
 </fieldset>

Additional examples of form controls are available on WebAIM’s article Creating Accessible Forms. WebAIM has also written an excellent article on Usable and Accessible Form Validation and Error Recovery.

Making PDF Forms Accessible

Interactive forms in Adobe PDF have many of the same issues as those described above. Labels and prompts must all be created in a way that explicitly associates them with their corresponding form fields. Also, PDF form fields have a tendency to be out of order, so you must be sure to test the tab order of your form, to be sure that users will move through the form in a logical sequence when jumping between fields using the keyboard. For additional information about forms, see our page  Creating accessible PDF Forms using Adobe Acrobat Pro