Warning: include(top.html): failed to open stream: No such file or directory in /data/www/world/accessit/print.html on line 3

Warning: include(): Failed opening 'top.html' for inclusion (include_path='.:/wwwudev/world/doit/Kb/Incs:/www/world/doit/Kb/Incs') in /data/www/world/accessit/print.html on line 3How can I develop accessible web-based forms?

Knowledge Base Printable Version

NOTE: This banner will not display when printed.

Please select a font size:

How can I develop accessible web-based forms?

DO-IT Factsheet #1159/articles?1159

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 <label> element, in combination with an "id" attribute for each form element. The <label> element was available starting with HTML 4.0. The basic technique is this:

Assign an id to the form element. Example: <input type="text" name="UserName" id="NameField">

Assuming the form element has a text label somewhere on the page, surround this label with <label> and </label> so the screen reader will recognize it as a label and will associate it with the specified id. Example: <label for="NameField">Your name:</label>

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 <label> elements?

The <label> element can be placed anywhere within the document. It makes no difference whether it precedes or follows the associated form element.

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 <fieldset> and <legend> elements. <fieldset> groups the controls, and <legend> 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 [2]. 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.