One of the more challenging tasks facing web developers is creating accessible online forms, particularly forms that are accessible to screen reader users. This is partly because there are a variety of form control types—text, checkboxes, radio buttons, menus, and others—each with its own distinct accessibility challenges. It is also because different screen readers handle these form control types in different and somewhat unpredictable ways.

For example, a JAWS user may attempt to complete an online form by activating "Forms Mode," a mode in which the user navigates among form controls using the TAB key or combinations of TAB, SHIFT, and CONTROL. Upon tabbing to a form element, that element gains focus, and JAWS announces certain information that it perceives to be relevant. Without specific accessible markup, however, JAWS is forced to make judgments about what information is relevant. For text boxes and text area boxes, JAWS announces the nearest text preceding the form control; for checkboxes, JAWS reads the nearest text following the form control; for radio buttons, JAWS reads the text preceding the complete set of radio buttons, plus (for each button) the text that immediately follows that button. If text labels are positioned differently from what JAWS expects, JAWS will provide either insufficient or incorrect information.

Other screen readers behave somewhat similarly, but there are significant differences across screen readers in how forms are processed, particularly concerning which information about a form control the screen reader judges to be relevant. So to make HTML forms reliably accessible to screen readers, web developers must tell screen readers what to say when they encounter specific form controls. This is primarily accomplished by using the

  • Assign an id to the form element.
    Example:
  • Assuming the form element has a text label somewhere on the page, surround this label with so the screen reader will recognize it as a label and will associate it with the specified id.
    Example:

This technique is described in greater detail, with examples, in the forms section of the Access Board Guide to Section 508 Standards.

Upon attaining a basic understanding of accessible forms design, however, web developers often continue to struggle with more complex questions. The following are among the most frequently asked questions regarding accessible forms:

Where can I place my

The

What if my visible label is a graphic? Will the screen reader use the graphic's "alt" attribute for its label?

No. Avoid using graphics to depict text, particularly in this context. To add style to your text, use Cascading Style Sheets.

With a group of form controls, such as checkboxes or radio buttons, the screen reader should announce both the text for the entire group and the text for each individual form control. How do I accomplish this?

Any related group of elements, such as a group of checkboxes or radio buttons, should be tagged using the

and elements.
groups the controls, and provides the label for the group of controls. More detail regarding this technique, plus some sample code, is available in the Forms section of the HTML 4.01 specification, specifically in 17.10 Adding structure to forms: the FIELDSET and LEGEND elements. If related groups of form controls are marked up appropriately, a supporting screen reader should announce both the group's legend and the specific control's label each time the user moves to a new control within the group.

Though developing accessible forms can be a complex process, it's a process that must be mastered, since forms are essential to the web being a dynamic and interactive resource. Forms are increasingly used in education for administrative functions, interactive curriculum, and assessment. Educational entities that utilize online forms must be aware of the techniques for ensuring that all students and staff are able to access them.