Forms

Electronic forms are more accessible than forms that are designed to be printed and completed by hand (imagine trying to complete a printable form as a person who is blind, or unable to read small print, or physically unable to write with a pen or pencil).

However, electronic forms must be created with care in order to ensure they’re fully accessible. For example:

• All form fields must have accurate labels or prompts so screen reader users know what each field is asking for.
• The tab order must be logical. As users navigate through the form using the tab key on the keyboard, they should land on fields in the expected order.
• Feedback, such as error messages, must be accessible to screen reader users.
• Fields that require users to perform actions with a mouse, such as drag-and-drop, must  be avoided unless they have accessible alternatives for keyboard users.

Online forms must be coded properly in order to be accessible. There a wide variety of issues that must be considered, and the form must be created with care.

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>

Providing supplemental help text

Only one <label> element is allowed per form field. However, if additional help text is available, it can be associated with the form field using the aria-describedby attribute. Screen readers will announce both the label and help text when the form field has focus.

<label for="DOB">Date of birth:</label>
<input type="text" name="birthdate" id="DOB" aria-describedby="DOB-help">
<span id="DOB-help">MM/DD/YYYY</span>

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.

Online forms must be coded properly in order to be accessible. There a wide variety of issues that must be considered, and the form must be created with care.

Forms in Microsoft Word

It is currently impossible to create an accessible interactive form using Microsoft Word. Word can be used to create a form template, but must then be exported to PDF and interactive form controls added using Acrobat Pro. See below for information about creating accessible PDF forms.

If possible, it is always better to use HTML forms, as HTML has much more extensive support for the features that are necessary for making forms accessible. For additional information, see our Forms on websites page.

Forms in PDF

Interactive forms in PDF have some of the same core issues as forms on websites. 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 it’s important to test the tab order of your form to be sure users will move through the form in a logical sequence when jumping between fields using the keyboard.

The following two workflows list the steps for creating a new form, and for fixing an existing form.

Creating accessible PDF forms using Adobe Acrobat Pro

• Do not create an interactive form using the original authoring tools’ form features
• Do not create a tagged PDF
• Use Acrobat Pro to make form fields interactive. Here’s how:

1. Automatically detect & markup form fields (Tools > Forms > Create)
2. Manually add/edit and form fields that weren’t correctly detected
3. Check tab order; repair if needed
4. Check all labels (tooltips); repair if needed
5. Check group labels and options for radio buttons; repair if needed
6. Check labels for checkboxes; repair if needed

Checking and repairing an existing PDF form using Adobe Acrobat Pro

1. Is form interactive?

If no, proceed to Creating Accessible PDF Forms using Acrobat Pro

2. Is tab order intuitive?

If no, correct it (Tools > Forms > Edit, play with Tab Order; select “Close Form Editing” when finished)

3. Are all text fields appropriately labeled? How to tell:

• Tools > Forms > Edit; look in Properties for ToolTip of each field, or
• Tab through form using Read Out Loud (View > Read Out Loud > Activate Read Out Loud)
• To fix labels on text fields:
• Right click on field; select Properties
• Enter a detailed, easy-to-understand prompt as Tooltip

4. Are radio buttons appropriately grouped and labeled?

• All radio buttons in a set should have the same name
• Tooltip is the overall prompt for the set (similar to legend in HTML)
• Labels for individual radio buttons within the set are defined using the Button Value field in the Options tab

5. Are checkboxes appropriately labeled?

• Checkboxes can’t be grouped like radio buttons. The workaround is to be sure the prompt for the overall set of checkboxes is clear within the tooltip for each option (for example, “Favorite Food: Tofu”, “Favorite Food: Steak”, “Favorite Food: Pizza”, etc.)
• Finishing touches
• Tools > Document Processing > Create Links from URLs
• Tools > Accessibility > Add Tags To Document
• Repair tags as needed
• Tools > Accessibility > Full Check