Guideline 10

Guideline 10: Use interim solutions

Many of the guidelines start with the phrase, "Until user agents". The W3C maintain a document that determines the current status of user agent support for accessibility. Developers are encouraged to consult the document on a regular basis for updated information. Unfortunately, the document isn't updated on a regular basis at all. At the time of writing, the last update was August 2001, nearly two years ago. I assume this is due to a lack of resources. The Web Content Accessibility Guidelines 2.0 became a working draft on the 29th April 2003, so hopefully the support for accessibility document will be revisited before it becomes a recommendation.

This guideline has 5 checkpoints, ranging in importance from Level "AA" (should be addressed for the site to be accessible), to Level "AAA" (beneficial to ensure the accessibility of your site).

10.1 Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user

This checkpoint is a priority 2 checkpoint. It should be satisfied for your site to be considered accessible. Popup windows can disorientate the visitor, so should be avoided. If you do cause a new window to be spawned, the link should clearly warn the visitor that it will open in a new window. Browsers such as Mozilla and Netscape allow users to turn off popup windows, and some user agents don't support popup windows at all. If you provide important information in a popup window, there's a chance that some visitors may never see the content.

Popups may cause problems with screen reading software, as the focus is changed, sometimes without warning. The screen reader begins reading the content of the new window, which can disorientate and confuse visitors. The target attribute has been removed from HTML 4.01 Strict, and XHTML Strict.

10.2 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

This checkpoint is a priority 2 checkpoint. It should be satisfied for your site to be considered accessible. A label is implicitly associated to a form control either by its position, or through markup. As screen readers read from left to right, the text for a form control should precede the control on the same line. The following example shows a label that is implicitly bound to a control through markup, using the label element.

<label>Forename:
< input type="text" size="20" value="forename"
name="forename" tabindex="5" />
</label>

The label has an implicit association with its contents, which is a prompt (forename:), followed by an input form element. The "for" attribute allows you to make an explicit association with a form control. The value provided for the "for" attribute must match the "id" attribute of an element in the document.

<label for="forename" accesskey="F">
Forename:
<input type="text" size="20" value="forename" id="forename"
name="forename" tabindex="5" />
</label>

As well as being explicitly bound to the form control, the label is also implicitly bound to the form control because of its positioning. A problem arises if you layout your form with a table, with the label in one column, and the form control in another column, as the label element cannot span across td elements. In this case, the form control is no longer implicitly bound to the label. Using the "for" attribute explicitly binds the control, but older user agents may not be able to associate the relationship. Modern user agents, including assistive technologies, are capable of handling explicit associations.

<td>
<label for="forename" accesskey="F">
Forename:
</label>
</td>
<td>
<input type="text" size="20" value="forename" id="forename"
name="forename" tabindex="5" />
</td>

10.3 Until user agents (including assistive technologies) render side-by-side text correctly, provide a linear text alternative (on the current page or some other) for all tables that lay out text in parallel, word-wrapped columns

This is a priority 3 checkpoint, which will be beneficial for the accessibility of your site. Tables should be used for tabular data, rather than layout. When tables are used for layout, it can cause problems with assistive technologies. If you use a table to split a page into two columns, some readers will read the first line of the first column, then the first line of the second column, and so on through the contents of the page. Unless the content of the table makes sense when reading the columns line by line, do not use tables. See guideline 5, for information on creating tables that transform gracefully.

10.4 Until user agents handle empty controls correctly, include default, place-holding characters in edit boxes and text areas

This is a priority 3 checkpoint, which will be beneficial for the accessibility of your site. Some older user agents require initial text in form controls such as the input text element, and the textarea element in order that they can function properly. Without the place-holding text, the fields can't be navigated to using a keyboard "TAB". Placeholder text can be provided with the text element using the "value" attribute, and for the textarea element by placing the text between the open and close tags.

<label for="forename" accesskey="F">
Forename:
<input type="text" size="20" value="forename" id="forename"
name="forename" tabindex="5" />
</label>
<br />
<label for="details" accesskey="D">
Personal Details:
<textarea id="details" name="details" rows="4" cols="50" tabindex="6">
Enter your personal details here:
</textarea>
</label>

Some developers use JavaScript to highlight the text when the control has focus. As the text is highlighted, it will be deleted as soon as the visitor starts to enter text into the field. The following example shows how to highlight text for an input form element using the onfocus event handler.

<input type="text" size="20" value="forename" id="forename"
name="forename" tabindex="5" onfocus="this.select();" />

Most modern user agents, including assistive technologies, are able to cope without place-holding text.

10.5 Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links

This is a priority 3 checkpoint, which will be beneficial for the accessibility of your site. Adjacent links should be separated by more than white space. Some user agents are unable to differentiate adjacent links, so they should be separated using text printable characters that are not part of the link. The following example uses a hyphen to separate the adjacent links.

<map title="Navigation Bar" id="NavBar">
<p>
<a href="/index.html" tabindex="1" accesskey="1">Home</a> -
<a href="/products.html" tabindex="2" accesskey="2">Products</a> -
<a href="/about.html" tabindex="3" accesskey="3">About Us</a> -
<a href="/contact.html" tabindex="4" accesskey="4">Contact Form</a>
</p>
</map>

Another acceptable solution is to place links in a list. This technique doesn't require printable characters to be placed between links, and is ideal for a navigation system as the links are easy to style in CSS.