facebook google plus twitter
Webucator's Free Web Accessibility and Section 508 Tutorial

Lesson: Accessible Forms

Welcome to our free Web Accessibility and Section 508 tutorial. This tutorial is based on Webucator's Web Accessibility and Section 508 Training for Experienced Web Designers course.

Lesson Goals

  • How to use HTML forms.
  • How to create accessible buttons.
  • How to create accessible form controls.

Form Basics

  • Section 508 requires that "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."

Forms consist of a number of possible input or interaction elements including the following.

  • Push buttons, input elements with type="button", type="submit", type="cancel" or type="reset".
  • Image buttons, input elements with type="image"
  • Generalized buttons, button elements
  • Text entry fields, input type="text" or type="password" (or no type) and textarea
  • Radio buttons, input elements with type="radio"
  • Check boxes, input elements with type="checkbox"
  • Select menus, select elements

Several of these are collected in a form element along with other content, including images and text. Usually form elements contain at least one submit button (button or input type="submit").

The accessibility issue for forms is whether or not users with disabilities, especially those who are blind or visually impaired, can determine the purpose of a specific form control and interact with it. A screen reader user will be aware that a text entry field has focus, or a text area or check box, but may not know what information to type there or what is being agreed to with the check. Screen readers try to guess which text corresponds to the on-screen prompt for a given control. Often they guess correctly, but sometimes they are wrong. That is the problem. Being correct most of the time is not good enough for filling out forms on the web.

The Section 508 standards include the following provision that applies to forms. Unlike other standards that prescribe specific actions, this rule states that forms must be accessible and leaves it to web authors to implement that accessibility.

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.

We'll go through each of the interaction elements that can appear in a form and discuss how to make them accessible and compliant with §1194.22 (n). For one of these input elements, push buttons, the accessibility issue is resolved by default. For the rest, you will have to provide some help for disabled customers.

Push Buttons

  • Value attribute is the text placed on the button, and talking browsers announce this value

Push buttons, input with type="button", and input with type="submit", include the value attribute, which is the text that is placed on the button, like "submit, "search," or "go." That text is immediately available to assistive technology.

<input type="submit" value="go" />

Go Button

When a user tabs to this kind of a push button, the button gets focus (a dotted focus rectangle surrounds the button text). And when the button has focus, the screen reader or talking browser knows to announce the text on the button, the value of the value attribute. In the example above, this value is "go." As a web developer, if you didn't put a text string on the submit button (no value attribute) then the browser will fill in text, either "Submit" or "Submit Query" depending on the browser.

<input type="submit" />

Submit Button

The special case of input with type="button" is kind of fun. If you don't provide a value for this button, no one, blind or sighted user will know what you intend:

<input type="button" />

Button

That is not likely to be a mistake you will make.

Image Buttons

  • the input element with type="image" must include the src attribute for the image source and alt attribute for the alternative text.
  • if the image has text, the alt-text should be the same as the image-text

Image button accessibility is provided by adding alternative text as explained for images and image maps in an earlier lesson. The input element with type="image" must include the src attribute for the image source and alt attribute for the alternative text.

<input type="image" name="Go" src="go.gif" alt="Go" />

Go Button

Remember, if the button has text, use that text for the alt-text. Doing otherwise is not a critical error or violation of the guidelines, but it can cause confusion. For example, the button below from target.com had alt="Proceed to Checkout" at the time that NFB brought suit against the Target Corporation. Imagine a telephone conversation between a sighted support person and a blind customer, with the support person saying "click on the Continue Checkout button" and the customer responding, "There is no Continue Checkout button" because the screen reader reads it as "Proceed to Checkout." Continue Checkout

Generalized Buttons

  • Button element allows both images and text on a button

The button element is a container that allows both images and text on a button. Images must have alt-text as we discussed earlier. The following is a rather ugly example.

Code Sample:

AccessibleForms/Demos/Code01.xml
<button name="submit" type="submit" />
		<strong>Go</strong> <img src="nextarrow.gif" alt="Next page" />
		</button>

Go with Arrow Button

When the text carries the message of the button and the image is redundant, then alt="" is good for the image. In the example above, alt="next page" was chosen for the alt-text, so for assistive technology the button reads "go next page" which is more information than a sighted user would get.

When a button receives focus, assistive technology knows to announce the content of that button, including alternative text on image buttons.

Text Entry Fields

  • Text entry fields need to be labeled

One of the most frustrating things about the web for a blind user is encountering a text entry field, and not having the foggiest idea what information to type into that field. This is not only an issue for screen readers and talking browsers. People who use magnification software, especially at magnifications greater than 4x, have difficulty finding the prompt for text entry fields because of the limited amount of data that fits on the magnified display.

If there is no labeling of the text fields, like that we're going to discuss now, screen readers will do their best and guess at what the prompting text is. They will guess by looking at what text is close by. Usually they get it right, say even 80 or 90 percent of the time. Sometimes they say nothing; sometimes they announce the wrong prompt. But when it comes to filling out forms on the web, 80-90 percent accuracy is not good enough. Follow the techniques that we will describe now, and you can be sure that assistive technology will present your form to the user with a disability with clarity and accuracy.

Make Sure Labels are Close to Text Fields

  • Text of a prompt should be:
    • physically close to the text entry field (either just above or just to the left)
    • close in terms of HTML, without intervening structural elements

As we stated above it is very important to be certain that the text of a prompt is close to the text entry field. It should be just above or just to the left. The prompt should be "physically close," as measured by pixels, but it is best if it is also close in HTML terms, without intervening structural elements. This is not the solution for screen readers; we will talk about label elements and title attributes below. This is for screen magnification. When the prompting information is close to the control, a screen magnifier is more likely to enlarge that information along with the control.

Below is a sample form in a table which has two rows and three columns. Here the prompts are close in pixels but not close in structural terms since there are intervening structural elements. A non-accessible horizontal form

This form is read like this with IBM Home Page Reader.

Code Sample:

AccessibleForms/Demos/Code02.xml
(Start of form 1.)
		Form in Horizontal Table
		First Name
		Middle Initial
		Last Name
		[Text.]
		[Text.]
		[Text.]
		(End of form 1.)

The first row of the table is read then the second row and so on. Sure it is possible to figure out that the third text entry field is the last name. But when a user is in the middle of listening to the page, and perhaps tabbing back and forth, it is difficult at best to figure out which prompt goes with which entry field. The critical idea is to programmatically connect the prompting text with each input element with the label element that we will discuss below.

What About the Prompt in the Text Entry Field?

  • Using this technique erases the default text before the required data can be entered.

Some recommend putting the prompt actually inside the text entry field. It can't be any closer than that!

This is very helpful to everybody using the form. Both sighted and visually impaired users can easily focus on the input box itself; if the prompt is there the required action will be obvious.

Here is a sample: Form with prompt in the text entry field

And, the corresponding HTML:

<input type="text" ... value="search words" />

The critical disadvantage of this technique is that the default text must be erased before the required data can be entered. This is not a recommended technique since it is difficult to erase that default text. In addition, after an entry is entered into the input field, a user may tab away and then return. Now the prompting information is gone. Thirdly, and most important, there is a much better technique supported by all the assistive technologies. In the example above the title attribute should be used, title="search words".

Associate Labels with Elements

  • Main technique for making sure each form control has the correct prompt
  • Two ways to use the label element:
    1. Use the label as a container of both the labeling text and the form control
    2. Use the label element with the for attribute whose value is the id of the input element (best method)

The label element is supported by assistive technologies. So the label element is the main technique for making sure that the correct prompt is associated with each form control.

The label element can be used in two ways.

The first way to use the label is as a container of both the labeling text and the form control as in the following example.

Code Sample:

AccessibleForms/Demos/Code03.xml
<label>First Name:
		<input type="text" name="fn" size="20" />
		</label>

That example has both the second and third techniques applied to it; the prompt "First Name" is close to its text entry field, and the prompt is programmatically identified to be "First Name" with the label element. Unfortunately, screen readers have difficulty with this use of the label element as a container, and one screen reader doesn't recognize it at all. So do not use the label as a container. Instead use the label element with the for attribute whose value is the id of the input element. The example above now looks like this.

Code Sample:

AccessibleForms/Demos/Code04.xml
<label <em>for="fn"</em>>First Name:</label>
		<input type="text" name="fn" id="fn" size="20" />

Notice that an id attribute has been added to the input element, and the value of the for attribute on the label element is the same as the value of the id attribute of the input. That is the programmatic connection of the prompting text with the control.

This labeling technique will work with screen readers no matter where the inputs and prompt are positioned. In a web accessibility class I use a form in which all the prompts are in one table (1 column and 6 rows) all the controls are in a second table (also 1 column and 6 rows). Without the label element, screen readers speak nothing for 5 of the controls and the wrong information for the sixth. When the form is labeled, using the label element, screen readers speak every prompt correctly.

The form in a table above is a case where screen readers would get it wrong. The following HTML code is for that example with the label element applied to each of the text entry fields:

Code Sample:

AccessibleForms/Demos/Code05.xml
<tr><th align="left">
		<label for="fn">First Name</label></th>
		<th align="left">
		<label for="mi">Middle Initial</label></th>
		<th align="left">
		<label for="ln">Last Name</label></th></tr>
		<tr><td>
		<input ... type="text" name="Fname" id="fn" />
		</td><td>
		<input ... type="text" name="Mname" id="mi" />
		</td><td>
		<input ... type="text" name="Lname" id="ln" />
		</td></tr>

This is the code for the table we saw above; it looks the same but now it is accessible. An accessible horizontal form

So far we have seen three techniques for associating prompts with text input fields. The first is to place the prompt close to the input field. That is a good idea, especially for people who can see the screen and who might be using magnification software - proximity really is important. For screen reader users, this technique will usually work, but you cannot be certain just based on proximity that a screen reader will announce the intended prompting information, so proximity is not enough.

The second technique, using the label as a container for both the prompt and the control, satisfies the proximity issue; and it should work for screen readers. Unfortunately, it is not dependable. Sometimes screen readers get it right; sometimes they don't. That leaves us with the last technique, using the label element with for and id attributes to programmatically tie the prompting information to the control. This is totally safe for screen readers. This should always be used when on-screen prompting text is available (more later about using the title attribute when that on-screen text is not available).

Radio Buttons and Check Boxes

  • Should be programmatically linked using the label element with for and id attributes.
  • Prompting information should be positioned close to, and to the right of any radio button or check box.

Radio buttons and checkboxes are similar to text entry fields except that for these input elements, the text should be just to the right. A form with radio buttons

Here is the way checkboxes should look: A form with checkboxes Checkboxes and radio buttons should be programmatically linked, like text entry fields, using the label element. Programmatically Linked Radio Buttons and Checkboxes

In the example above, the fact that prompts and input elements are in different table cells just adds to the requirement that those prompts be identified with the label element. Here is the HTML for the second radio button with the appropriate label element included:

Code Sample:

AccessibleForms/Demos/Code06.xml
<tr valign="top">
		<td align="right">
		<input type="radio" name="user" value="returning" id="r2" />
		</td><td>
		<label for="r2">I am a returning customer:</label><
		and <label for="pass">my password is:</label><
		<input type="password" size="30" id="pass" />
		</td>
		</tr>

The last input field is a password field (type="password") and screen readers can inform the user of that fact. The explicit labeling with the label element reinforces that association.

Always position prompting information close to and, in this case, to the right of any radio button or checkbox. And always programmatically connect the prompting information with the control using the label element with for and id attributes.

There is another construct introduced in HTML 4.0 that is especially important for radio buttons and to a lesser extent checkboxes. This is the combination of fieldset and legend elements. The fieldset element is a container that groups form controls, and the legend element gives a name (or legend) to the group. So the radio buttons above (male and female) could be placed in a fieldset with the legend, gender. If this is done, the question to be answered by the radio buttons is the legend, and that question is programmatically tied to the radio buttons. Screen readers today will read the legend with each control in the fieldset which is great for "gender male" and "gender female" but can become tiresome when the legend is longer and when the fieldset includes many controls. Here is the way the gender example looks. A form demonstrating fieldset and legend tags

And here is the code.

Code Sample:

AccessibleForms/Demos/Code07.xml
<fieldset>
		<legend>Gender?</legend>
		<input type="radio" id="m" name="g" /><label for=�m�>Male</label>
		<input type="radio" id="f" name="g" /><label for=�f�>Female</label>d
		</fieldset>

So for now screen readers announce the legend for every control in the fieldset. Hopefully, that will be modified in the future so that the legend is spoken for the first control in the fieldset, and there is a simple "where-am-I" type key that would include the legend for any control in the fieldset.

It is possible to obtain very interesting styling of the fieldset/legend code. Check out the Man in Blue web site.

Select Menus

  • Use the label element with the for and id attributes to programmatically connect the prompting information.

Select menus (or combo boxes or drop-down menus) are, for accessibility, similar to text entry fields, and all the techniques discussed previously apply to them -- with one notable exception.

The one difference between text entry fields and select menus is that the technique of placing the prompt in the select menu has less of a disadvantage for select menus. If the prompt is placed in the select menu as the selected (default) item with, say, a null value (value=""), then the users will encounter the prompt as they Tab to the select menu the first time. A form demonstrating a select menu

The code for this select menu looks something like this:

Code Sample:

AccessibleForms/Demos/Code08.xml
<select name="ship_to_state" size="1">
		<option selecedD value="">State/Province </option>
		<option value="AL">Alabama </option>
		<option value="AK">Alaska </option>
		<option value="AB">Alberta </option>
		...

The disadvantage of using a default option in the menu itself for the prompt in this way is that when you make a selection, move away and come back, the prompt is no longer there. In this example when one tabs away from the menu and comes back and hears "Select menu Alaska", it is pretty obvious where you are; but if you heard "Select menu 28", then you would have to ask, which of the numeric fields was that - age or date? So it is much better to handle the labeling as in all the cases above. Use the label element with the for and id attributes to programmatically connect the prompting information with the select menu. In part because of the default selected value technique and in part because of positioning, it is often the case for select menus, more than other controls, that there is no prompting text around to capture with the label element. We deal with that common situation with the title attribute.

Title Attribute for Form Controls

  • Indicate the purpose of the control by using the title attribute in the input element when on-screen prompting information is not available.

Search forms often provide an example of controls that lack on-screen prompting text. The screenshot below is cut from the IBM web site. IBM.com search form

The form consists of a text entry field (input with type="text") and a push button with value="Search". There is likely to be no question in a sighted visitor's mind what goes in the entry field; but for a blind user, they would land on the text entry field, and their screen reader would just say "edit" or "edit box" with no hint as to what goes there. It is true that continued exploration would give a very good clue ("button search"), but that is extra effort that is completely unnecessary if the title attribute is added to the input element, title="search". With that, screen readers will announce "Search edit".

It is interesting and a bit daunting that this is not what IBM does. Instead they use an invisible image, place alt="Search for:" which is announced "Search For colon" by JAWS, and warp the image in a <label> tag:

Code Sample:

AccessibleForms/Demos/Code09.xml
<label for="q"><img src="//www.ibm.com/i/c.gif" width="1" height="1" alt="Search for:" /></label>
		<input id="q" maxlength="100" name="q" type="text" />

There is nothing inherently wrong with this technique, though it is a kind of "hack". Unfortunately, some testing tools don't yet recognize the title attribute as a valid way to satisfy the forms provision in Section 508, so that may be the reason IBM uses this technique.

The label construct is in a sense inadequate because it can only assign text to one form element. If the prompt is at the left side of a row in a table of input elements, you cannot use the label element to associate that prompt with each of the form elements in the row (because id's must be unique). If an input element is characterized by two pieces of text, say column and row headers, then the label element can technically tie two pieces of text to one control, but in tests of this configuration, none of three screen readers picked up both pieces of information.

Here is an example of a table of input elements that might occur in a hypothetical web-based tax form. A form demonstrating fieldset and legend tags

We discuss tables in detail in the lesson on Accessible Tables. One might hope that table navigation with a screen reader would automatically speak the properly marked up table headers. That would be true when navigating the table in "web mode" or tables reading mode. But a user is going to be listening to these controls in forms mode, not in table reading mode, and in this situation the table headers are not spoken.

The title attribute for the input elements provides a simple and clean strategy of labeling in this case. Here is part of the code for the table above with the title attributes filled in.

Code Sample:

AccessibleForms/Demos/Code10.xml
<table cellpadding="0">
		...
		<th>W2 Gross</th>
		<td><input type="text" size="20" title="taxpayer w2 gross" /></td>
		<td><input type="text" size="20" title="spouse w2 gross" /></td>
		</tr><tr>
		<th>Dividends</th>
		<td><input type="text" size="20" title="taxpayer dividends" /></td>
		<td><input type="text" size="20" title="spouse dividends" /></td>
		</tr></table>

The last few versions of the major screen readers all support the title attribute on form controls. So when on-screen prompting information is not available or is dispersed, i.e., when the label element won't work, use the title attribute in the input element (or select menu, etc.) to indicate the purpose of the control.

It is important to use the label element, if possible, so that visible text is what is heard by screen reader users. That way, when the text changes, screen readers will hear the change, whereas the "hidden" title attribute might not keep up with changes.

An Example Collection of Form Controls

  • Techniques ensure meeting the Section 508 requirements:
    • Make sure prompting text is physically close to the associated form control
    • Always use the label element to specifically associate the prompting text with the input element
    • Use the title attribute on the input element to specify the purpose of the control if the on-screen text is not adequate.

The following is a screenshot of a section of the page encountered when placing an order on Amazon. Amazon.com cart page, screenshot

There are five input controls shown in the screenshot of the Amazon.com cart page. If those were marked up correctly as we have discussed in this lesson, then screen readers would provide the correct prompting information for each control. Because the prompting information is awkwardly placed or nonexistent, screen readers have a tough to impossible time figuring out what to say. Here is a table of how each control should be labeled (the first column), and the way Window-Eyes and JAWS read the form controls in normal "web mode" (columns 2 and 4) and in "forms mode" (columns 3 and 5). How Controls are Read by Screen Readers

The lesson from this table is that you must label all input controls with the label element or with the title attribute; if you do that, blind customers can proceed with confidence when interacting with your site, whether searching for information or entering important personal data like credit cards or phone numbers.

Accessible Forms

Duration: 15 to 35 minutes.

In this exercise, you will create an accessible form.

  1. Open the file /AccessibleForm/Exercises/exercise.htm.
  2. Correct the code to make the form accessible.
  3. Save your work.
  4. Compare with the file /AccessibleForm/Solutions/solution.htm.