Site navigation

Accessible Forms

Roger Hudson, July 2004

Contents

Many web sites all ready use forms. They allow the users of goods or service to register online. Internet shoppers use forms to select, pay and arrange for the delivery of their purchases.

As the Web grows, more and more transactions will be done online bringing benefits to all Web users. We are increasingly going online for example, to do our banking and shopping, request information, book travel, pay bills and participate in education and training courses. In most cases, all this is possible at a time and from a location of our own choosing.

In many ways the freedom and flexibility of online transactions has the potential to be of the greatest benefits to people in the community with disabilities. The Web could allow tasks that many now find very time consuming and difficult to become relatively simple and in the process open up new opportunities. All of this is possible, but only if everyone can access the forms that facilitate online transactions.

The aim of this document is not to provide an introduction into making forms for the Web and it does not consider how the information obtained by a form is collected, processed and presented. The many books, Websites and online tutorials devoted to preparing forms will help you do this.

This document is concerned with what the user of a Website form "sees" and interacts with. It outlines how you can create forms for the Web that are more accessible and describes the appropriate use of;

Although the examples in this document use standard HTML, no attempt has been made to control their layout or appearance. When preparing a form for a Website the presentation of form elements can and should be controlled using Cascading Style Sheets.

Forms: Accessibility and Assistive Technologies

Forms can present problems for Web users with vision and/or mobility impairment and for people with cognitive or learning disabilities. It is very easy for someone with impaired vision who relies on an assistive output device such as a screen reader, talking browser or Braille display to get lost in a form. For these technologies to work effectively the devices need to be able to associate a form label (request or prompt) with the correct form control, such as a text field or checkbox.

Many people with vision and mobility disabilities interact with the Web (and forms) using primarily the keyboard rather than a mouse. As a result their interactions tend to be sequential with the sequence order largely controlled by the way the Website or form have been designed. Sighted Web users without impaired mobility on the other hand, can use a mouse to move around the screen randomly by a simple point and click.

Some people with mobility impairment require modified keyboards or alternative input devices input such as a mouth stick or head wand, which operate via a simple on/off switch. For people with restricted mobility accessibility can be greatly enhanced by reducing the number of movements or interactions they have to make when filling in a form.

A form that is well designed with good visual layout will benefit all sighted users. For people with learning or cognitive disabilities the logical presentation of items in form, where associated information and requests are grouped together, can be essential. A well-organised form is easier to understand and use effectively.

Labelling Form Elements

"Associate labels explicitly with their controls. For example, in HTML use LABEL and its "for" attribute."
Web Content Accessibility Guideline Checkpoint 12.4

A form with text boxes and radio buttons that don't have labels (prompts or requests for information) is likely to be pretty well useless for all Web users. We have to be able to associate a form label, such as "name", with its input element, which in the case of "name" is likely to be a text box. On the screen this association is usually done visually.

This type of visual association works well for those who can see it, however it is also possible to make the association work for people who use output devices that convert the information into speech or Braille.

The HTML tags label for and id can be used to associate a text or graphic label with a specific form input (or control). The tags can be used with any of the input elements, for example text boxes, text area, checkboxes and radio buttons, however the id attribute for each element (checkbox, text field etc) in a document must be unique.

While it is usual for the form label or prompt and the control to be adjacent to each other, or at least in close proximity, it is possible to associate a label with a form control that is placed anywhere on the same Web page.

As we will see shortly the title attribute can also be used to make forms easier for everyone, not just people with disabilities.

Example

The following example shows how the label for and id tags are used to associate a label with an input textbox.

<label for="phonehm">Phone Home:</label>
<input id="phonehm" type="text" title="type your home phone number" name="homephone" size="15">

With this result on the screen:

A screen reader like JAWS or Connect Outloud will read this as:

"Phone Home. Edit (hypertext)"

If there is already something in the text field it will then be read.

The user can accept what is already in the text field or delete it and make a new entry hearing the letters as they are typed. They can also go back and hear the whole entry again if they wish.

The use of label for and id with checkboxes is very similar as shown below:

Select the fact sheets you want</b><br>
<input id="roses" type="checkbox" title ="rose factsheet" name="roses" value="checkbox">
<label for="roses">Roses</label>
<input id="daffodils" type="checkbox" title="daffodil factsheet" name="daffodils" value="checkbox">
<label for="daffodils">Daffodils</label>
<input id="tulips" type="checkbox" title="tulip factsheet" name="tulips" value="checkbox">
<label for="tulips">Tulips</label>

With this result on the screen:

Select the fact sheets you want

You will notice however that with checkboxes (and radio buttons) the input element (or control) comes before the label. This makes it easier for someone "hearing" the form to use it. The form section above will be read as:

"Select the fact sheets you want
Roses checkbox not checked. Daffodils checkbox not checked. Tulips checkbox not checked."

The user can check a checkbox when they hear it. And, if the Tulips box was, for example, already checked they would hear "Tulips checkbox checked".

Another benefit from the use of the label tag is an increase in size of the area that can be clicked to access the form control. This is particular helpful for people with diminished vision or fine motor skill but who are still able to use a mouse. With a text input, clicking anywhere on the label or textbox will put the cursor at the beginning of the text input area. Similarly, a radio button or checkbox can be checked by clicking either the label or button (or box).

HTML provides another attribute, title, which can help improve accessibility. The title attribute (not to confused with the <title> tag in the head section of a page) is usually associated with images and links where it causes a tool-tip-style comment to appear when the cursor is over the element. In fact, title can be used with virtually all Web page elements and can be particularly useful with Web forms.

The title attribute should be used with all input elements (textfield, checkbox etc) in a form to provide users with information about the element and what is required. For example, enter your phone number with area code.

Using Layout Tables for Forms

Unfortunately, not all browsers and assistive technologies fully support the label for attribute. As a result, the spatial relationship between a form label and input element is important and care needs to be taken when using tables to layout a form.

"Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels ensure that the label is properly positioned."
Web Content Accessibility Guideline Checkpoint 10.2

The use of tables to layout forms can cause accessibility problems and so where possible it should be avoided. However, when it is necessary to use tables, the layout of the form must provide close relationship, in HTML-table terms, between the form label (request or prompt) and the input element.

Although the way screen readers handle layout table has improved considerably in recent years, they still linearize the way they present information, moving from row to row, top to bottom, and across each row from left to right reading the entire content of one cell before going on to the next. (Some earlier screen readers ignored tables altogether and read across the entire screen from left to right).

In the following example, a table with two rows and three columns is used to present three form requests and the associated input text fields.

Request 1: Requests 2: Request 3:

A screen reader will read the content of each of the cells in the first row and then the cells in the second row like this:

"Request 1. Request 2. Request 3.
Edit (hypertext). Edit (hypertext). Edit (hypertext)."

Clearly, associating form label Request 2 with the appropriate input field, for example, is going to be a lot harder for someone who is listening to these form elements than it would be for a person who can see them. The solution is to place the both the form label and the input in the same cell or in adjacent cells as shown below.

Example

The easiest way of associating a label with an input element is to put them both within the same table cell < td> </td> tags.

<table>
<tr>
<td>
   <label for="rq1">Request 1:</label><br>
   <input id="rq1" type="text" name="Request1" size="20">
</td>
<td>
   <label for="rq2">Request 2:</label><br>
   <input id="rq2" type="text" name="Request2" size="20">
</td>
<td>
   <label for="rq3">Request 3:</label><br>
   <input id="rq3" type="text" name="Request3" size="20">
</td>
</tr>
</table>

With this result on the screen:




Connect Outloud (JAWS) reads the table form above like this:

"Request 1 edit. Request 2 edit. Request 3 edit."

When using layout tables, another effective way of associating the form label and input is to place them in adjacent table cells. Note the request cell is before the input cell.

<table>
<tr>
<td>
   <label for="rq1">Request 1:</label>
</td>
<td>
   <input id="rq1" type="text" name="Request1" size="20">
</td>
</tr>
<tr>
<td>
   <label for="rq2">Request 2:</label>
</td>
<td>
   <input id="rq2" type="text" name="Request2" size="20"> </td></tr>
<tr>
<td>
   <label for="rq3">Request 3:</label>
</td>
<td>
   <input id="rq3" type="text" name="Request3" size="20">
</td>
</tr>
</table>

With this result on the screen:

Request 1:
Request 2:
Request 3:

This table form with adjacent cells will be read like this:

"Request 1 edit. Request 2 edit. Request 3 edit."
(Same as above)

Grouping Form Elements

A form where different elements are well organised with similar ones grouped together is easier for everyone to use. Grouping form elements together can be particularly helpful for people with cognitive or learning disabilities.

The HTML 4 elements <fieldset> and <legend> allow you to layout and organise a large form with many different areas of interest in a logical way without using tables. The <fieldset> tag can be used to create boxes around selected elements and the <legend> tag will give a caption to those elements. In this way form elements can be grouped together into identified categories.

Example

<fieldset>
   <legend><b>Personal Details</b></legend>
   <label for="name">Name:</label>
   <input id="name" type="text" name="name" size="30"> <br>
   <label for="id">ID Number:</label>
   <input id="id" type="text" name="id number" size="10">
</fieldset>

Producing something like this on the screen:

Personal Details

Different browsers may display the default <fieldset> border in different way. Cascading Style Sheets can be used to remove the border or change its appearance.

Setting the Tab Order

"Create a logical tab order through links, form controls, and objects. For example, in HTML, specify tab order via the "tabindex" attribute or ensure a logical page design".
Web Content Accessibility Guideline Checkpoint 9.4

Many browsers now allow users to navigate a Web page using only the keyboard. People, who are unable to use a mouse for either physical or technological reasons, rely on the keyboard and in particular the tab key to move around Web pages and the Web as a whole.

Within a Web page, pressing the tab key will move the focus from one page element to the next, for example going from links to images and then through the various elements in a form. By default, tab movement through a page follows the page layout from top left to bottom right. However, the use of layout tables may mean that the tabbing order does not necessarily follow the logical visual order of the page as it appears on the screen. In addition, with forms the visual order may not always be the ideal order for someone using assistive technologies to fill it in.

The tabindex attribute allows you to set the tab order for a Web page. Including tabindex attributes with link (and link anchor) tags will enable users, for example, to tab from one area of site navigation to another and then onto the page content.

For tabindex to work effectively all elements that are to be accessible by tabbing must contain the tabindex tag. Pressing the tab key will then select elements in ascending order depending on the value of the tabindex. For example, a link with tabindex="1" will be selected before one with tabindex="2" and if a form element has a tabindex="3" it will then be selected.

The tabindex attribute can use numbers up to 32,767. In the example above, the numbers count up in ones, however a strict ordering like this is not necessary. With tabindex it doesn't matter which numbers you use so long as they are in ascending numerical order. In fact, it is common to miss out numbers, going up in hundreds for example, so that new elements can be easily inserted between existing elements in the future without extensive renumbering.

With Web forms, tabindex can be applied to all the input elements such as buttons, checkboxes and text areas. Pressing the tab key will move the focus to the next element, for example tabbing through a form with a number of input boxes will place the cursor at the beginning of each box in the order determined by the tabindex for each box.

Example

<fieldset>
   <legend tabindex="100"><b>Personal Details</b></legend>
   <label for="name">Name:</label>
   <input id="name" type="text" name="name" size="30" tabindex="110"><br>
   <label for="id">ID Number:</label>
   <input id="id" type="text" name="id number" size="10" tabindex="120">
</fieldset>

Where tabindex is used and supported by the browser, all the elements with a tabindex of between 1 and 32,767 will be navigated in ascending order. Then an element with tabindex="0" will be navigated followed by elements without a tabindex in the order they appear.

Browser support for tabindex is not complete, however the inclusion of tabindex attributes will not interfere with the functioning of browsers that do not support them.

JavaScript and Device Independence

The JavaScript contained in a Web page is only functional when that page is accessed via a browser that is able to interpret it. A significant number of online forms use JavaScript and in some cases this can make the form inaccessible.

The requirement for client-side browser support of JavaScript is the crux of the accessibility concerns over its use since not all browsers and assistive technologies support JavaScript.

"Ensure that pages are usable when scripts, applets etc are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page."
Web Content Accessibility Guideline 6.3

JavaScript uses "event handlers" to trigger certain actions when an event occurs however, not all screen readers support all event handlers. For scripts that do more than just change the presentation of an element, content developers should use event triggers that are device-independent, since many people with disabilities rely on assistive technologies and are unable to use a computer mouse.

"For scripts, specify logical event handlers rather than device-dependent event handlers."
Web Content Accessibility Guideline 9.3

All forms should be keyboard accessible and should not contain elements that depend on the use of the mouse or are automatically activated by JavaScript. Some forms use "select and go" drop-down menus, which are mouse dependant. When the user makes a selection from the list of options with the mouse, the selection is immediatley activated. In some cases, this may take the user to a new page or automatically call up information from a data base.

Keyboard users are able to access the options in a standard combo drop-down menu by using the arrow keys. However with a "select-and-go" menu, the first action (pressing the arrow key) is interpreted as a selection and the user is sent to the page linked to that option. As a result, it is not possible for a non-mouse user to see the other options or make a choice from them.

"Select and go" drop-down menus should not be used. Rather, all form elements that allow the user to select from a range of options presented in a drop-down menu should have a separate "submit" or "go" button to activate that selection.

Other Accessibility Issues with Forms

Colours and Fonts

Some people with vision disabilities are unable to discriminate between certain colours or may not be able to distinguish text from its background if there is insufficient contrast between the two. In general, use colour very sparingly with forms, and if used there should be considerable difference in contrast between the text and the background.

Also, many users find the default font size on Websites is often too small for comfortable reading. This only becomes a major problem if the user is unable to increase the font size with their browser, so relative font size attributes should always be used. With forms, you need to ensure that when the font size is increased in this way the text and different elements don't overlap.

Error Messages

Avoid using organisational jargon or code for error messages. Error messages should provide an indication of the problem and offer advice on how it might be corrected.

Timed Responses

It can take considerably longer for a user of assistive technologies to read or listen to information on the screen and fill in forms. This needs to be taken into consideration when setting server timeout limits.

References and Additional Information

Books

Websites

Accessibility tools

Use these accessibility tools to customise the site to suit your needs.

Text size:
Normal
Larger
Text style:
Sans-serif
Serif
Page layout:
Normal
PDA
Reset all:
Default settings