Accessible Forms

Overview

To create an accessible online form, you must ensure that all form fields have accurate labels or prompts so screen reader users know what each field is asking for.  Forms typically have labels or prompts that are obvious to sighted users, but their association with particular form fields is made based on visual cues, such as relative position and proximity to the field. Since screen reader users don’t have access to these same visual cues, labels and prompts must be explicitly associated with form fields within the HTML. Following are a few techniques for accomplishing this.

Techniques

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 idattribute 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.

See also Using Accessible Methods of Form Validation.

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 Creating accessible PDF Forms using Adobe Acrobat Pro.

Avoiding CAPTCHA

CAPTCHA (an acronym that stands for “Completely Automated Public Turing test to tell Computers and Humans Apart”) is a type of form field that is sometimes used to determine whether a user is human, in an effort to prevent computers from automatically submitting online forms. Often CAPTCHAs assume the form of distorted characters such as those shown in the image below. 

CAPTCHA is inaccessible to many groups of users, including people who are blind or dyslexic. If audio CAPTCHA is provided as an alternative for these users, that still is not a solution for people who are deaf-blind. Also, CAPTCHAs are burdensome for everyone, and increase the likelihood that people will fail to submit the form or complete the task. A variety of creative alternative solutions have been proposed that do not burden the user. For example, see Hannah Alvarez’s article on UserTesting.com.

References