Building Accessible Web Applications

Steve Faulkner

TPG (Europe)

The Basics: form control prompts

Does every control need a prompt?
Prompt Placement
Implicit versus Explicit Association
Use of the label element
Use of the title attribute
Use of the first option element within a select element
Use of default input text (in general and as a prompt)
Multiple labels for a control
hidden labels
tab order

form control prompt examples - No prompt

No prompt

<input type="text" name="search"> 
<input type="submit"  value="Search">

Recommended

<input type="text" name="search" title="Search criteria"> 
<input type="submit" value="Search">

form control prompt examples - multiple actions

text input with multiple actions

<input type="text" name="searchtext"> 
<input type="submit" name="mail" value="search mail">
<input type="submit" name="web" value="search the web">

Recommended

<input type="text" name="searchtext" title="Search"> 
<input type="submit" name="mail" value="search mail">
<input type="submit" name="web" value="search the web" title="search the web: opens in a new window">

The Basics: prompt placement

Before control; in left-to-right languages, either to the left or immediately above the control. Buttons are self-labelled prompts. Check boxes and radio buttons are special types of buttons, and so the prompt is part of the button (increases target area), and placed immediately after the control to show the semantic difference

Prompt Placement
Control	Prompt
text, text area, select	To the left or immediately above
check box and radio buttons	Immediately after the control
buttons	self-labelled

The Basics: Implicit and Explicit Association

Implicit/Explicit Labels

Implicit

Prompt: <input type="text" size="30" name="uname">

<label>Prompt: <input type="text" size="30" name="uname"></label>

Explicit - Recommended

<label for="uname">Prompt:</label>
<input type="text" size="30" id="uname" name="uname">

Hybrid

<label for="uname">Prompt: 
<input type="text" size="30" id="uname" name="uname">
</label>

Implicitly positioned labels do not work correctly in IE6 and lower, and with some screen readers (JAWS 6.2; probably others, but don't know). The for attribute in the hybrid version makes it an explicit association. Implicitly associated labels are made available through MSAA, and are legal according to the specification, making this a user agent problem. Having said that, I don't like implicit associations. Semantically, a label is associated with its form control; it doesn't make sense to say the prompt is the parent, and the form control is its child. It would make more sense to say that the prompt is part of the form control, as they are in XForms.

The Basics: Option as a prompt

<select name="city">
	<option value="-1">choose a city</option>
	<option value="1">Birmingham</option>
	<option value="2">London</option>
</select>

Acceptable

<select name="city"  title="choose a city">
	<option value="-1">choose a city</option>
	<option value="1">Birmingham</option>
</select>

City Recommended

<label for="city">City</label>
<select name="city" id="city">
<option value="-1">choose a city</option>
	<option value="1">Birmingham</option>
	<option value="2">London</option>
</select>

When there's no default option, it's useful to make the first option a prompt, but it should provide context, and the control should still have an explicit label (or title attribute). Relying on the first option as a prompt might work in some circumstances, but it soon breaks. For example, if a mistake is made, the user's selections should be retained. They now have a drop-down box whose label is a value that might not be accurate.

Basics: Multiple labels for a control

name first name optional

<label for="multi1">name</label> 
<input type="text" id="multi1" name="multi"> 
first name optional

name first name optional

<label
 for="multi2">name <input type="text" id="multi2" name="multi">
 first name optional</label>

name first name optional

<label for="multi3">name</label> 
<input type="text" id="multi3" name="multi"> 
<label for="multi3">first name optional</label>

name (first name optional) Recommended

<label
 for="multi4">name (first name optional)
 </label> 
 <input type="text" id="multi4" name="multi">

Use of hidden labels

search criteria

search criteria

.hiddenlabel {
 position: absolute;
 left: 0;
 top: -999em;
 width: 1em;
 height: 1em;
 overflow: hidden;
}

Recommended

<input type="text" id="search3" name="search3" title="search criteria"><input type="submit"  value="Search">

Labelling of form controls in data tables

Product order form
code	item	quantity	price
123	pencil	quantity of pencils (code 123) required	$1.00
124	pens		$1.50

<td>
<label class="hiddenlabel" for="q1">quantity of pencils</label>
<input type="text" id="q1" name="q1" size="3" value="0"></td>

Recommended

<td>
<input type="text"  name="q1" size="3" value="0" title="quantity of pens"></td>

Labels increase click area

over 35
clickable area is 400px
over 65
clickable area is 1293px
I agree
I agree

Grouping: fieldset and legend elements

Personal Details Title First Name Middle Name Last Name

<fieldset>
  <legend>Personal   Details</legend>
  <label for="t6">Title</label>
  <select name="ddlTitle">
  <option>Mr</option>
  <option>Ms</option>
  </select>
  <label for="t1"> First Name</label>
  <input type="text"id="t1" name="txtFirstName">
  <label for="t2">Middle Name</label>
  <input type="text"id="t2"cname="txtmiddleName">   
  <label for="t3">Last Name</label>
  <input type="text" id="t3" name="txtlastName">
  </fieldset>

Grouping: fieldset and legend - continued

Search This Site Search for

filter by television radio cinema

<fieldset>
<legend>Search This Site</legend>
<label for="searchfor">Search for</label> 
<input id="searchfor" name="searchfor" type="text">
<fieldset>
<legend>filter by</legend>
<input type="radio" id="a" value="1"> <label for="a">television</label> 
<input type="radio" id="b" value="2"> <label for="b">radio</label> 
<input type="radio" id="c" value="3"> <label for="c">cinema</label>
</fieldset><input type="submit" value="search">
</fieldset>

Use of the tabindex

The tabindex attribute specifies the position of the current element in the tabbing order for the current document
Valid for elements that can receive focus (a, area, button, input,object, select, and textarea)
The tabindex attribute expects values between 0 and 32767
The lower the number, the earlier the interface element will be visited (except zero)
A tabindex attribute value of zero "0" means the element is navigated in the order it appears naturally in the source order
Although intended to be an accessibility aid, explicit tabindex values often cause problems, as they're easy to go out of sync, resulting in a tab order that is unexpected and confusing to the visitor unless great care is taken.

Use of the tabindex - continued

Only interface elements can receive focus from JavaScript (using the object.focus() method)
Adding a positive tabindex attribute value to a non-interface element explicitly puts the element into the tabbing order
- Not legal according to HTML 4.01 and XHTML 1.0
- Not supported by all user agents
If a tabindex attribute value of 0 is used on a non-interface element, the interface element will be added to the browser's tabbing order at the order it appears naturally in the source order
If a tabindex attribute value of -1 is used, the element will not be added to the browser's tabbing order (it won't be possible to navigate to the element using the keyboard), but it is possible to set focus to the element with JavaScript.
A component such as a slider would require adding to the tabbing order so that it can be operated with the keyboard; in this case, you would use tabindex="0". If you need to be able to focus on the element, but do now want it appearing in the browser's natural tabbing order, you would use tabindex="-1"
focus examples (new window)

CSUN 2007