Guideline 9

Guideline 9: Design for device-independence

Visitors to your site use a variety of input/output devices, such as mouse, keyboard, voice, head wand, etc. You should design your pages so that visitors using any of these devices have full access. Designing pages that rely on a mouse makes the content inaccessible for those using keyboard, voice activation, or any other non-pointing device. It's generally considered that pages that allow keyboard interaction are also accessible through speech input, or using a command driven interface.

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

9.1 Provide client-side image maps instead of server-side image maps except where the regions cannot be defined with an available geometric shape

This checkpoint is a priority 1 checkpoint. It must be satisfied for your site to be considered accessible. Server side image maps send the coordinates of the mouse to the server for further processing. You should avoid using server-side image maps if possible, as they are inaccessible to text only browsers, visitors using only a keyboard, and some assistive technology programs. The only time a server-side image map should be chosen over a client-side image map is when the geometric shapes are unable to define the map.

The following list shows the geometric shapes supported by the area element.

• default: Specifies the entire region.
• rect: Define a rectangular region.
• circle: Define a circular region.
• poly: Define a polygonal region.

If you find you have to use a server-side image map, you should provide redundant text links.

<p>
<a href="http://www.yourdomain.com/processmap.asp">
<img src="map.gif" alt="Map of area (text links below)" ismap="ismap" />
</a>
</p>
<p>
[<a href="start.html">Start</a>]
[<a href="middle.html">Middle</a>]
[<a href="end.html">End</a>]
< /p>

9.2 Ensure that any element that has its own interface can be operated in a device-independent manner

This checkpoint is a priority 2 checkpoint. It should be satisfied for your site to be considered accessible. Elements that have their own interface must be accessible and compatible with assistive technology (see guideline 6.4). If the interface cannot be made accessible due to limitations in the type of object, then an alternative accessible solution should be provided. See guideline 8 for more information on creating device independent interfaces.

9.3 For scripts, specify logical event handlers rather than device-dependent event handlers

This checkpoint is a priority 2 checkpoint. It should be satisfied for your site to be considered accessible. Your scripts shouldn't depend on a particular input device. See guideline 6.4 for an explanation of device independent event handlers. Writing scripts that are dependent on a mouse, for example, will be inaccessible to visitors using non-pointing devices, such as a keyboard. Where possible, you should use events that require no user intervention, such as onsubmit. Event handlers that are written for a mouse should contain a redundant keyboard event handler to make it accessible.

<a href="somewhere.html"
onclick="window.open(this.href); return false;"
onkeypress="window.open(this.href); return false;">Somewhere</a>
(Opens in a new Window if JavaScript is enabled)

In the above example, if JavaScript is enabled, then clicking on the link, or pressing a key when the element has focus will cause a new window to be launched. It isn't dependent on a particular input device. If JavaScript isn't enabled, the page is opened in the current window.

9.4 Create a logical tab order through links, form controls, and objects

This is a priority 3 checkpoint, which will be beneficial for the accessibility of your site. Visitors using a keyboard can navigate through the active elements on a page using the "TAB" key. The elements should follow a structured order. Pages are sometimes presented in a manner where the links don't follow a structured order. For example, style sheets may affect the logical order of active elements on a page.

To test if the elements on the page follow a structured order, press the tab key repeatedly, and make sure that the elements follow a structured, logical order. If they don't, then you should specify a tabindex for the active element on the page. Valid values for the tabindex are a number in the range 0 to 32,767. The lowest number is visited first.

<form id="loginDetails" method="post" action="login.asp">
<fieldset>
<legend>Login Details</legend>
<p>
<label for="username" accesskey="U">
Username:
<input type="text" size="40" value="username" id="username"
                            name="un" tabindex="5" />
</label>
<br />
<label for="password" accesskey="P">
Password:
<input type="password" size="40" value="" id="password"
                                name="pw" tabindex="6" />
</label>
</p>
</fieldset>
<p>
<input type="submit" value="Login" name="loginButton" tabindex="7" />
</p>
</form>

9.5 Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls

This is a priority 3 checkpoint, which will be beneficial for the accessibility of your site. Access keys provide a quick and efficient means of navigating a site using the keyboard. Most browsers support access keys, allowing you to navigate to active elements using a keyboard combination. Invoking an access key depends on the operating system, and the user agent being used.

Invoking Access Keys on a Windows Operating System

• Internet Explorer 4+: Alt + [key], followed by Return
• Netscape 6+, and Mozilla 1+: Alt + [Key]
• Opera 7+: Shift + Esc + [Key]

Invoking Access Keys on a Macintosh Operating System

• Internet Explorer 5+: Ctr + [key], followed by Return
• Netscape 6+, and Mozilla 1+: Ctr + [Key]
• Opera 6+: Shift + Esc + [Key]

Access keys are not supported under Mac OS 9, and Mac OS X 10 by Mozilla.

Invoking Access Keys on a Lynux Operating System

• Galeon 1+: Alt + [key]
• Mozilla 1+: Alt + [Key]

The shortcut is provided through the accesskey attribute.

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

Using letters for access keys can be problematic, as they may interfere with pre-existing shortcuts in the user agent. For example, Alt + "F" is used to access the File menu in Mozilla and Internet Explorer. Providing an access key of "F" will interfere with the typical behaviour users who navigate with keyboards expect. Many accessibility pundits get around the problem by using numbers instead of letters, as there is less likelihood that it will clash with existing shortcut keys. Even using numbers for access keys has its problems, as IBM's Home Page Reader, a popular screen reading application, uses Alt + 1 to read the headings on a page.

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

You should provide a guide that informs the visitor of any access keys you use on your site, as most user agents do not detect them automatically. One technique is to use the after pseudo class along with the attr function in CSS for links that contain access keys.

#navBar a:after
{
    content: " [" attr(accesskey) "] ";
}

It's advisable to create an accessibility statement that explains the accessibility features implemented on your site. The accessibility statement should ideally be placed in a prominent position on your home page.