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.
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.
This form is read like this with IBM Home Page Reader.
(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.
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:
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".
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.
<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.
<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:
<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.
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).