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.
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.
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 HTML5 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 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 HTML5 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:
Ensure Client-side Errors are 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 immediately after the form field with 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 Errors are 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:
- 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.
- Stylize the error message so it is visually prominent and easy to spot.
- Preface the error message with a high-level heading (preferably <h1>) that includes the word “Error” so users can jump directly to that message.
- Include clear, specific details in the error message, such as a list of the fields that have errors and the nature of those errors.
- Provide a same-page link that enables users to jump directly from each error message to the form field that requires correction.
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.
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.
External WCAG References
Most Details from this page were gleaned from the University of Washington's Accessible Technology section.