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 I. Forms and the OSU Minimum Web Accessibilty Standards

Forms and the OSU Minimum Web Accessibility Standards

MWAS #14 When electronic forms are designed to be completed online, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.

The language of the MWAS covering forms could be considered unclear or offering little guidance to the form designer. It is clear that forms must be compatible with "assistive technology." But how functional is "functionality required"? And which "assistive technology"?

There is good reason, however, for this vague language. Electronic forms can be created in a myriad of ways PDF forms, HTML forms, script-based forms, database-driven forms. Some forms use server-side processing like ColdFusion or PHP, while others rely on client-side scripts, like JavaScript. Because the Standards Committee could not predict or adequately cover all the various types of forms, they put the burden on the form designer to properly code and test her forms to insure at least a minimum compatibility with the most popular assistive technology (or with the one most used by her identified user group). When the user population cannot be clearly defined, the WAC tests for compatibility with the most current versions of both JAWS and WYNN screen-reader technologies. Generally, when content is made available to a screen-reader, it will be available to other assistive technology (screen enlargers and focus aids) as well.

Distributing Printed Forms Via the Web.

MWAS 14 only applies to forms "designed to be completed online." Whether submitted via e-mail, processed on the server, or saved to electronic document to share with others, electronically submitted forms must be made accessible to assistive technology users. However, if you are using your web site to distribute paper copies of your forms (less the cost of printing them) and fully expect that users download/save, print, complete, and submit a paper copy of the form, you do not need to make the form input accessible. However, you need to make enough of the document accessible, so users can identify which form they are downloading and can successfully save and print the file. For forms intended to be printed, whenever possible, it is still a good idea to use a well-organized layout and clean text that can be scanned and read by a text reader.

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.

Elements of Accessible Form Design

Regardless of how you choose to create your form, in general an accessible form requires two key elements: 1) clear instructions on how and what to input into the form and 2) ability to navigate the form using only the keyboard.

Instructions and Labels.

In order to meet the first requirement for an accessible form, every element in the form (i.e., text boxes, radio buttons, drop-down lists, menus) must have a LABEL which defines the expected input for the element and provides an additional instructions necessary to completing the required input. The LABEL must be defined in such a way as to insure that when the user puts the focus on the form element, the label information is read along with the element. This tutorial focuses on how to create HTML labels for each form element; however, you can also create labels in Adobe Acrobat and other form-generating software. You should familiarize yourself with the methods for adding labels to your forms using your particular software. It is not enough to put text next to a form element; this text is often ignored or misinterpreted by assistive technology.

Keyboard Access.

Depending on the complexity of your form, insuring keyboard access to all form elements and functions can be an automatic feature or require more extensive coding. Additionally, some form elements available to designers, such as Jump Menus, do not support keyboard only access.

Related to keyboard access is the issue of tab-order, or the order in which the cursor moves through your form using the TAB key to move from form element to form element. Adobe Acrobat, for instance, assigns a tab-index to each form element in the order the elements are inserted. Thus, if you insert a text box for the first name, then a text box for the phone number, and then a text box for the last name, keyboard users will be asked to input the information in that order. While this does not prevent the user from using the form, it can make for a confusing and cumbersome entry process. Thus, we suggest testing your form's read-order and adding necessary mark-up to redefine this order, if necessary.

Summary of Elements for Accessible Form Design.

• Required elements for accessible forms: explicitly associated labels for each element.

• Recommended: tabindex and/or access keys.

Form Layout and Design.

As you design your form, consider that unless you define a different read-order, screen readers read forms left to right from top to bottom. Make sure that this configuration represents a logical input order for users.

When considering how you are going to layout your form, keep in mind these guidelines:

1. Except for check boxes and radio buttons, labels should be before (to the left of) the form element. For check boxes and radio buttons, labels should be directly after (to the right of or below) the box or button.

2. Avoid putting the label in one table cell and the form element in another. If using tables, put both label and form element in the same cell or be sure to use explicitly associated labels.

3. Group like fields into FIELDSETS to help users relate form fields.

4. Insert form fields in the order you want the screen reader to use them. Even better, use the "tabindex" attribute for each form element to explicitly define the order in which the form is accessed by the keyboard (TAB key).

Processing Forms

Form processing can be generally categorized into three areas: e-mail forms, client-side forms, and server-side forms.

E-mail Forms.

Actually, there are two types of e-mail forms: forms where the data is reformatted into an e-mail message and sent via server-side scripting and forms where users must have an e-mail program installed and setup to send via their own e-mail server. The first type of e-mail form is both highly accessible and more secure. The second type puts a lot of the requirements on the user. When users click "send e-mail," the form may automatically open the user's default e-mail program (which may or may not be the one the user typically uses) and all e-mail settings must be configured by the user to successfully send the document. If the user does not have an e-mail account, the form may be completely useless.

If the only setup that your server supports is to have users manually e-mail their forms to you, ask users to download/save the form and fill it out offline. Additionally, make it clear at the beginning of the form that users need an active e-mail account to submit the form online. And, expect that some users will send you the information directly without using the form to format their responses.

Client-Side Forms (JavaScript).

Generally speaking, client-side scripting means that some relatively simple code, which is embedded into an HTML document or referred to in it, is executed by the user's browser (e.g., IE, Netscape, Opera, or Firefox). Currently the most popular client-side scripting language is JavaScript. JavaScript can be used to populate the form's entries (such as a list or menu), verify the user's input, and submit or redisplay the information in the desired format.

As with the external e-mail client described above, requiring users to have a certain configuration (i.e. a JavaScript enabled browser) presents several barriers to accessibility:

1. Some assistive technology disables JavaScript automatically when browsing the web.

2. Many users disable JavaScript to avoid ads, pop-up windows, and nefarious programs. In particular, certain IT networks disable scripting to prevent hacker attacks and other security issues.

3. It may be difficult, even for experienced browsers, to turn JavaScript support back on if it has been disabled. This is especially true for IE users.

4. JavaScript processing can cause lengthy delays or even crash the user's system, depending on how much memory and processor work is required.

Scripting and the OSU Standards.

Because it is not fully supported by assistive technology, the OSU Standards (MWAS#12) actually prohibits users from relying on client-side scripting to display content or process information. You may use scripting to enhance the page add decorative elements, layout content, or add additional navigation features but you may not use it as a primary or required element on your pages. Thus, OSU designers should use an alternate method of form validation and processing.

Workarounds for Scripting.

If you must use client-side scripting:

1. Inform users, in plain, non-script dependent text, that the form requires a script-enabled browser. If possible, use a detection method to automatically detect if scripting is turned on and direct the user accordingly.

2. Provide detailed and explicit instructions for turning on scripting in various browsers, especially IE. Link to these instructions from your form page.

3. Offer a method to request a non-script-dependent version of the form. Be sure users can easily request the form in alternate format and that they are not prevented from receiving the benefits of the form if it is submitted via an alternate route. For instance, if a user requests an alternate version of a grant application and the application is due the same day, the user must have reasonable time to complete and submit the alternate version and equal consideration as those who were able to use the online form.

Server-Side Forms (JAVA, ColdFusion, PHP, etc.).

As a general rule of thumb, forms processed and submitted via server-side processing (for example, using ColdFusion or PHP scripting) are the most accessible type of forms. This is because, in most cases, users are not required to have any special software other than a browser capable of displaying the form. Since all processing happens on the server-side, the user's operating system, browser version, or firewall connection has minimal effect on the functionality of the form.

Error Messages and Notations.

When a users presses the "Submit" button, typical a form is passed-through a validation process, either using client- or server-side validation techniques. If the user incorrectly enters information, leaves required fields blank, or otherwise tries to submit invalid data, the validation process can return the user to the input screen and flag problem fields.

Tips for identifying invalid input:

1. If the validation process reloads the current page or returns the user to the same input page as was displayed before submit, put a "errors found" message at the top of the page, so screen reader users know that a problem occurred and don't have to read through the whole page again to find out what happened and why their Submit didn't work.

2. Use more than color to indicate which fields require corrections. Turning a field or input red doesn't help those who can't see the screen or have colors turned off.

3. Put error messages to the right or above form fields. This insures that screen readers will read the error before the form field and the error is associated with the appropriate field.

4. If users are required to enter a lot of data using a particular set of formatting (e.g. "All lower case only and no numbers or spaces." or "Use dashes to separate entries"), consider creating an instruction page and linking from the form page. Thus, users can read all the instructions first, then go to the form or can refer back to the instructions, when needed, without interrupting "Forms Mode" entry.

Marking Up HTML Form Elements.

In this section, we will consider each of the form elements and what information you need to include to insert these elements into your HTML form. Although we focus on HTML forms, the requirements are similar regardless of what kind of form it is PDF, scripted, or other although it may be more difficult to add the appropriate accessible markup.

You can view a form with examples of all these elements on our Sample Form.

Text Boxes.

Text boxes require a unique label and unique ID for each box. Attach the label to the text box by using the "for" attribute in the LABEL tag. The "for" attribute should equal the "id" attribute in the INPUT tag.

In FrontPage, type the label and insert the text box, then use the insert label feature to attach the two. Dreamweaver identifies all text boxes as "textfield." You need to add unique names/ids and change the "for" in the LABEL tag to reflect that unique name.

<p align="left">
<label for="first">First Name:</label>
<input name="first" type="text" id="first" tabindex="5" size="30" />
<label for="last">Last Name:</label>
<input name="last" type="text" id="last" tabindex="7" size="30" /><br />
<label for="email">E-mail Address:</label>
<input name="email" type="text" id="email" tabindex="9" size="50" /></p>

Example of Text Boxes:

Text Areas.

Text areas, like text boxes, are also fairly straight forward. In most cases, engaging the "Return" button once inside a text area will create a new line of text and not send the form. But, be sure to test how your server interprets this action. Most problems occur when using client-side processing to validate the form (validates on detection of ENTER key).

<p align="left">
<label for="question">Tell us your question:</label><br />
<textarea name="question" cols="50" id="question" tabindex="19">
</textarea></p>

Example of Text Area:

Radio Buttons.

Radio buttons are the most problematic form element for users of assistive technology. In particular, for JAWS users, it can be difficult to engage "Forms Mode" when the cursor is focus on a radio button. In addition, when a group of radio buttons are used to answer a single question, it can be difficult to associate both the question and answer with each radio button. Finally, users can only turn a radio button on not off and at least one radio button must be selected in the group, making it very import to offer a "None" or "Does not apply" option. The WAC recommends using radio buttons sparingly and instead choosing a list or drop-down menu.

Tips for Using Radio Button Groups:

1. The only way to associate the general question with the radio button options is to add FIELDSET And LEGEND tags around the entire collection of radio buttons. Keep in mind that the entire LEGEND text is read before each option, so keep it short and to the point.

2. Each radio button must be assigned a unique ID and that ID must be reflected in the associated LABEL "FOR" attribute.

3. Be sure to include a "None" or "Not Applicable" choice, so users can "turn off" or deselect an incorrect choice. In most cases, it is best to make this the default choice.

4. Note that Dreamweaver wraps the LABEL tag around the INPUT tag. Although it should not matter, this may cause some browser errors. To be extra careful, reposition the tag.

<div align="left">
<fieldset>
<p align="left"><legend>Are you a current student?</legend><br />
<input type="radio" name="cur_student" value="grad" id="grad" tabindex="13"/>
<label for="grad">Current Graduate Student</label><br />
<input type="radio" name="cur_student" value="ugrad" id="ugrad" />
<label for="ugrad">Current Undergraduate Student</label> <br />
<input name="cur_student" type="radio" value="none" checked="checked" id="none" tabindex="15" />
<label for="none">None: not a current student</label><br /></p></fieldset></div>

Example of Radio Buttons (inside FieldSet):

Check Boxes.

In most cases, check boxes are preferable to radio buttons, because users can turn each box on ("checked") or off ("unchecked"). However, they are still a rather clumsy method of offering multiple choices the WAC recommends using the Menu/List box instead.

Check boxes resemble text boxes in that each box must be given a unique ID and the label tag must be updated for each. Also, Dreamweaver does not assign a default value for each check box, so you must add this. FrontPage assigns each check box the value of "ON," which you can change, if desired. Like the radio button, add the FIELDSET and LEGEND tags to connect boxes related to the same form question/topic.

<div align="left">
<fieldset>
<legend>Would you like to join any of the department listservs? (check any that interest you)</legend>
<input type="checkbox" name="list_dept" value="dept list" tabindex="20" id="list_dept" />
<label for="list_dept">Department Listserv</label><br />
<input type="checkbox" name="list_grad" value="Gradlist" tabindex="21" id="list_grad" />
<label for="list_grad">Graduate Student Listserv</label><br />
<input type="checkbox" name="list_ugrad" value="ugrad list" tabindex="23" id="list_ugrad" />
<label for="list_ugrad">Undergraduate Listserv</label><br />
<input type="checkbox" name="list_18th" value="18th cen list" tabindex="25" id="list_18th" />
<label for="list_18th">18th Century Literature Listserv</label>
</fieldset></div>

Example of Check Box Group:

Menus and List Boxes.

Menus and list boxes are excellent choices for presenting multiple options in one field. They can be limited to accept only one answer or to allow multiple selections. Both FrontPage and Dreamweaver automate much of the work for accessible menus and list boxes.

Notice in the example below that each OPTION tag does not require a separate label. Wherever a form element includes a VALUE attribute that attribute serves as the label for that form element.

<p align="left">
<label for="topic">What is the topic of your question (choose best):</label><br />
<select name="topic" size="1" id="topic" tabindex="17">
<option value="none" selected="selected">Choose topic</option>
<option value="gradstudies">Information on Graduate Study</option>
<option value="ugrad">Information on Undergraduate Study</option>
<option value="web">Problem with web site</option>
<option value="course">About course currently being offered</option>
<option value="futurecourse">About future course</option>
<option value="department">General question about deparment</option>
<option value="faculty">General question about faculty or staff</option>
<option value="other">Other: not listed</option></select></p>

Example of Menu Box (with drop-down menu):

Jump Menus.

One very problematic form of the menu/list box the Jump Menu. When a user selects an option in a Jump Menu, a script, link, or other action is automatically engaged. Thus, the user only needs to click on the object once. However, keyboard users can only select the first item as soon as it is selected by the keyboard, the action is engaged and users cannot scroll down the rest of the list.

Instead of a Jump Menu, add a "GO" or "Select" button next to the menu to allow users to initiate the action with an additional click. Note that this option typically relies on JavaScript or other client-side scripting to make the GO button work and should therefore not be used as the primary navigation method (See "Processing Forms" below).

Buttons (Submit and Reset).

The like the OPTION in a menu or list, the "value" attribute serves as the label for button elements and should therefore be as simple and clear as possible. In particular, note if engaging the button leads to a "next step" (data verification) in the form process and not to the completion/submission of the data.

<p><input type="submit" name="Submit" value="Submit Your Question" tabindex="27" id="Submit" /></p> </form>

Example of Button: