Forms are one of the most ubiquitous and important features on many websites. Whether searching for content, reporting a problem, or applying to college, forms provide a structure for users to communicate their needs or supply information.
Much has been written about designing usable forms, but design trade-offs often depend on the context of use. Web Form Design: Filling in the Blanks by Luke Wroblewski is an excellent reference for all things related to online forms.
When it comes to creating accessible forms, there are some definite best practices:
The good news is that if you choose to use the Forms Web Service at Stanford, or Qualtrics surveys, many potential issues related to accessibility will be addressed for you. If you use Qualtrics, please be sure to review and follow the instructions to Check Survey Accessibility.
Although there are some exceptions, discussed below, in general, every form control needs to have a label that identifies its purpose, or what information is to be entered. The label must be visible, and it must use correct HTML markup in order to associate the label with the control. Simply positioning a text label next to the control, i.e., not associating the label with the control via HTML, will force screen reader users to perform extra keystrokes in order to read the label and interact with the control.
Form labels can either be “explicit” or “implicit.” While implicit labels are not specifically excluded in WCAG 2.0, screen readers may not support them in all circumstances. For this reason, explicit labels are recommended.
Explicit labels use the HTML label element with a “for” attribute that has the same value as the matching input “id” attribute. This associates the label with the form control. Here is a simple example from a WebAIM article, Creating Accessible Forms:
<input id=”name” type=”text” name=”textfield”>
The WebAIM article includes sample code for defining explicit labels for a variety of different types of controls, such as buttons, checkboxes, radio buttons, drop-down menus, etc.
Another reason for using explicit labels is that the user can click on the label itself to put focus into the form element, e.g., a text box or checkbox. This effectively makes the cursor target larger and can help people with fine motor disabilities.
Because search fields are so pervasive on websites, users generally know what to expect and how to use them. For this reason, many developers don’t provide a visible label for search boxes. In this case, a “title” attribute can be used to identify the control to screen reader users, for example:
<input type=”text” title=”search>
With HTML5, many developers have started using placeholder text inside text boxes instead of labels. This looks nice visually, but it creates accessibility and usability problems. Furthermore the W3C HTML5 placeholder specification states that placeholder text should be a “short hint” and “the placeholder attribute should not be used as an alternative to a label.”
Visible labels should be placed adjacent to the form control, whether it’s a text box, checkbox, radio button, selection menu, etc. Text box labels are usually placed above or to the left of the control (left or right justified) while labels for checkboxes and radio buttons are usually placed to the right of the controls.
Regardless of its actual placement, using an explicit label will always associate the label with its corresponding control for screen reader users.
For screen magnification users, it’s important that the label be as close as possible to the control so these users don’t have to scroll between the label and control. Therefore, if the labels are located to the left of the control, right justification is preferred.
See The Definitive Guide to Form Label Positioning by Jessica Enders for an excellent discussion of the trade-offs regarding label placement on text boxes.
Many, or most, forms include some fields that are required and some that aren’t. To indicate required fields:
The most common ways of indicating required fields are the word “Required” or an asterisk, often in red so that it stands out visually. If most fields on the form are required, another option is to indicate which fields aren’t required with the word “Optional.” Whichever method is used, it is important that the word or symbol be part of the explicit label associated with the control.
Note that It is also possible to use ARIA-required. See the WAI-ARIA page for details about ARIA roles, states, and properties. A general understanding of ARIA will help contextualize some of the references to it when considering forms.
If form controls have required formats, e.g., dates, it’s best to include that information in the explicit label.
Fieldset and Legend
To make complex forms more usable by everyone, you should group related controls using the <fieldset> element and label the group using <legend>.
Note that some screen readers read the legend with every form element, some read it once, and some don’t read it at all. To accommodate all screen readers, make the legend as short as possible for situations in which it is read every time, and make individual labels descriptive for situations in which the legend isn’t read at all. Alternatively, you could hide the legend visually and provide a heading with the same text as the legend. However, this results in the same text being read twice for some screen reader users.
When navigating by keyboard, the tab key should move sequentially from form control to form control (and shift-tab to go backwards). It’s important that each control has a visual focus indicator and that the tab order follow the visual order on the screen.
When landing in a text box, the input cursor should be visible.
When landing on a checkbox or radio button, the space bar should make a selection.
The Enter key submits the form.
A detailed discussion of accessibility as it relates to server and client-side validation is beyond the scope of this overview article, but here are a few recommendations for further reading. Please take care to watch dates, especially with these articles, since support for WAI-ARIA is steadily improving.
Three posts from Deque:
Also, this Form Validation Example from the Paciello Group may provide a useful code sample.
Errors should be communicated clearly to all users. For example, using color alone will not be sufficient. Ideally, errors could be listed at the top of the page and allow the user to jump to each one. Or it is possible to manage focus and provide written and visual guidance to enable users to locate errors quickly. Including errors in form labels can be helpful, too. Simply Accessible has three useful articles on this topic.
Use of CAPTCHAs
When possible, alternatives to CAPTCHAs should be used. And if a CAPTCHA must be used, there should be, at minimum, an audio alternative. When using the Stanford Web Forms Service or Qualtrics, this is not an issue, but it could become one if you choose to build and host your own form. There are many articles that discuss the inaccessibility of CAPTCHAs and offer other approaches to eliminate spam. This Smashing Coding article called "In Search of the Perfect CAPTCHA" is a good place to start.
Forms and Mobile Users
The concepts outlined here would apply, generally, to forms presented via a mobile browser or specific mobile app; however, in some cases, implementation strategies may be different. See the Mobile page on the SOAP site for an overview of the mobile and accessibility landscape.