Forms

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.

While it is technically possible to make a PDF accessible, doing so requires a high level of specialized skill in PDF accessibility, and the end result is still a form that can be challenging for users with disabilities to complete. 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.

If PDF is necessary, the primary goals for accessibility are:

1. Ensure all labels and prompts are created in a way that explicitly associates them with their corresponding form fields.
2. Ensure the read order is correct. 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 fixing an existing form. Both workflows assume you are using Adobe Acrobat Pro.

Creating new PDF forms

• 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

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)
4. To fix labels on text fields:
   • Right click on field; select Properties
   • Enter a detailed, easy-to-understand prompt as Tooltip
5. 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
6. 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.)
7. Finishing touches
   • Tools > Document Processing > Create Links from URLs
   • Tools > Accessibility > Add Tags To Document
   • Repair tags as needed
   • Tools > Accessibility > Full Check

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>

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>

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>

Even if forms are coded properly for accessibility, users may make mistakes. They may inadvertently skip required fields, or enter invalid information. A well-designed online form provides helpful and timely feedback to users so they can easily correct errors and resubmit the form. When providing feedback to users, it’s important to ensure that feedback is accessible to screen reader users. The following techniques can all contribute toward accomplishing this.

Use both client-side and server-side validation

Client-side validation (using JavaScript) provides more immediate feedback, which can improve accessibility if implemented well. Server-side validation should be used as a fallback in case the user’s invalid submission slips through the cracks.

Avoid disabling the submit button. Some forms have disabled submit buttons that are enabled only after the form meets certain requirements. However, this can be very confusing for users if they discover they can’t submit but aren’t informed as to why.  If you’ve provided them with client-side errors yet they’ve still reached the submit button without correcting the errors, let them submit the form, then reload the page and provide them with easy-to-discover errors on the new page.

Use HTML attributes and input types

HTML5 includes a variety of new input types and attributes that will ultimately be very helpful for accessibility as browsers and assistive technologies build in support of this new standard markup.

For example, the HTML5 required attribute can be used to identify required fields. When this attribute is present, screen readers inform the user that the field is required when the field receives focus. If users exit the field without entering anything or making a selection, the browser displays an immediate error which is fairly well supported by screen readers.

Also, HTML5 introduces several new input types (e.g., tel, url, email, date, time, color). Once fully supported, these will standardize form fields that have historically been added to web pages using widgets built with JavaScript, typically at the expense of accessibility. As standardized form fields provided by the browsers, users will encounter consistency across websites, and assistive technologies can more easily build in support for them. If browsers don’t support a particular input type, it is simply displayed as a text field.

Use HTML validation methods

One of the most powerful new features of HTML5 is its support for validation built into the HTML of the field. This is very easy to maintain with minimal code, and is highly accessible since the error messages come directly from the browser and are well-supported by screen readers. In addition to the required attribute described in the previous section, HTML5 also includes the pattern attribute, which can be used to define specific patterns of acceptable input for the given field using regular expressions. There are some very good articles online that provide additional details regarding HTML5 validation techniques. For example:

• HTML5 Form Validation by Ian Oxley, on sitepoint.com
• Client-Side Form Validation with HTML5 by Collins Agbonghama, on sitepoint.com

Ensure client-side error handling is accessible

If you are using JavaScript to do client-side validation and write errors to the screen, be sure to do so in a way that is accessible to screen reader users. For example, display errors in a container that includes the attribute role=”alert”. Screen readers support role=”alert” by interrupting users immediately when the content of that item changes, without the users’ losing their focus on the page.

Also, position the error container immediately after the form field and include the attribute tabindex=”0″, so if screen reader users don’t hear the alert, they are likely to discover it immediately after leaving the form field.

Ensure server-side error handling is accessible

If a submission fails server-side validation and the user is returned to the same page to correct the errors in their form, use these techniques to ensure that users are aware that there are errors and can easily find them:

1. Change the <title> element of the page so it includes the word “Error”. Screen readers are likely to announce the title immediately when the page is loaded, so providing this information up front will make users aware that there are problems requiring their attention.
2. Stylize the error message so it is visually prominent and easy to spot.
3. Preface the error message with a high-level heading (preferably <h1>) that includes the word “Error” so users can jump directly to that message.
4. Include clear, specific details in the error message, such as a list of the fields that have errors and the nature of those errors.
5. Provide a same-page link that enables users to jump directly from each error message to the form field that requires correction.

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.

Google reCAPTCHA, starting with version 3, moved in a promising new direction as it operates behind the scenes and doesn’t burden the user. However, if it fails to recognize a user as human it defers to the content provider to provide some means of handling that user, which could result in inaccessible CAPTCHAs being used as a secondary test.  The W3C maintains an extensive working group note on Inaccessibility of CAPTCHA, which describes a wide variety of alternative solutions.