Creating Accessible Forms: Overview

WAC Workshop. November 2004.
Written and Presented by: Lori Bailey.

Covers: OSU Standards and electronic forms, distributing forms, screen readers and forms, elements of accessible form design, form layout, inserting and marking-up form elements, processing forms and error messages.

Part II. How JAWS Reads Forms

Before we begin designing electronic forms, it is probably a good idea to get familiar with the assistive technology your users might use to access the form. One screen reader we use to test for accessibility is JAWS. JAWS is one of the most popular and most powerful screen readers available. It is the primary program used in elementary and secondary schools in Ohio and is therefore the software supported by the ODS staff at Ohio State.

Which Version?

The current version of JAWS is 5.10 and unlike some other software, the difference between version 5.0 and 5.10 is significant and can affect how successful a user is when using online forms. Additionally, JAWS 5 represents a huge leap forward from JAWS 4, which supported very little non-HTML web content such as PDFs and scripting. Assistive technology is also very expensive with an educator's discount, JAWS will cost around $900 and users do not get automatic access to the latest version without purchasing a new license. Thus, you can expect that some of your users are accessing your site with an older version of JAWS and you may need to think about what additional steps you can take to insure access for them. For instance, JAWS 5.10 is very good at interpreting which label goes with which form element, if labels have not been properly assigned. Older versions of JAWS are less successful. To insure consistency, the MWAS requires that all labels be "explicitly associated" with their corresponding form elements, so screen readers don't have to try and make that interpretation.

A form compatible with JAWS version 5.10, but not earlier versions will be considered to meet the OSU Standards. However, you will need to inform users of this limitation upon accessing the form page and you'll need a system in place to allow users to request alternate accommodations and to provide those accommodations in a timely manner. Rather than coding to the latest version, many designers prefer to include as much additional markup as possible to make their forms available to as many titles and versions of assistive technology as possible and avoid the issue of additional accommodations. It is up to the individual designer to assess their users' needs and decide if backwards-compatible support is needed.

"Forms Mode On"

JAWS has special support for form reading and input, which it calls "Forms Mode." Users can toggle "Forms Mode" on and off at any time, but more typically, JAWS automatically turns it on when the user enters the first form element. Once in "Forms Mode," JAWS only reads the information that is included in a form element or label it does not read extraneous text or information around the form elements.

For example, let's consider this simple login form:

The form pictured above has two input boxes for user name and password and one submit button. Here is the HTML used to create this form:

<form name="testform" id="testform" method="post" action="">
<p><label for="user">User name:</label>
<input type="text" name="user" id="user" /> (Email address: xxx@xxx.xxx)</p>
<p>
<label for="pw">Password:</label>
<input type="text" name="pw" id="pw" /> (must include one number: 0-9) </p>
<p>
<input type="submit" name="Submit" value="Login" id="Submit" /></p>
</form>

JAWS will only read enclosed in LABELS or form element tags. The instructions are ignored. So, this is what a JAWS user hears:

Forms mode on
User name: edit, type in text.
Password: edit.
Login button, to activate press space bar.

For the user to hear the instructions, she must toggle Forms Mode off and then navigate back up the page (using the arrow keys or hot keys). Then, she must navigate back to the edit box, turn Forms Mode back on and input the appropriate information.

By moving the close of the LABEL tag to include both the label and instructions, we eliminate this problem and streamline data input. Here is the revised HTML:

<form name="testform" id="testform" method="post" action="">
<p> <label for="username">User name: <input type="text" name="username" id="username" />(Email address: xxx@xxx.xxx)</label></p>
<p><label for="pw">Password: <input type="text" name="pw" id="pw" /> (must include one number: 0-9)</label> </p>
<p><input type="submit" name="Submit" value="Login" id="Submit" /></p>
</form>

With this configuration, the user only has to navigate to the form elements once and all needed instructions are read.

As you design your forms, you need to keep in mind what users will have access to in "Forms Mode." Once it is turned on, users can only navigate the page using the TAB key (not the arrows or hot keys) and the screen reader will only recognize form elements and labels.