Accessibility Tutorial

Developer's Guide Part 4

Forms

All form elements should have a label associated with them. Developers must not rely on visual clues to help users associate text with their respective elements. The value of the LABEL element's for attribute must match the form element's id.

<label for="firstName">First Name</label>
<input type="text" id="firstName" />

While it is true that you can wrap the label around its respective element to associate them without the use of an id and the label for attribute, it is best not to do this because some screen readers will not make the association.

All forms should have at least one fieldset—a fieldset is required in XHTML—with each distinct section of the form in a separate fieldset. Each fieldset should have a label, which is handled by the LEGEND element. The legend is especially useful for aiding users of screen readers to associate radio button labels with their respective buttons.

<form>
  <fieldset>
    <legend>Email format</legend>
    <label for="text">Plain text</label>
    <input type="radio" name="emailFormat" id="text"/>
    <label for="html">HTML</label>
    <input type="radio" name="emailFormat" id="html"/>
  </fieldset>
</form>

Without the FIELDSET and LEGEND elements screen readers might say, "plain text radio button HTML radio button." With the addition of these elements, the legend is repeated before each label: "Email format plain text radio button email format HTML radio button." This is especially helpful if there are several radio buttons. This method is useful for checkboxes too.

It is best to keep the legend text short since it will be repeated for each button. Another reason for keeping it short is that the LEGEND element is also very difficult to style in visual browsers.

Drop lists, or combo boxes, require special attention. The OPTGROUP element aids in accessibility for all users, and has a label attribute—not to be confused with the LABEL element—which is useful for screen readers. The OPTGROUP element groups OPTION elements in a list.

<select>
  <optgroup label="domesticCars">
    <option value="chevy">Chevy</option>
    <option value="ford">Ford</option>
 </optgroup>
 <optgroup label="importedCars">
    <option value="nissan">Nissan</option>
    <option value="toyota">Toyota</option>
 </optgroup>
</select>

Note that multiple select menus are troublesome in IE6, and are generally not needed since checkboxes can be provided.

Error Display

Error checking must occur on every page that contains a form. At the very least this error checking should occur on the server side in case JavaScript is turned off. But error checking should also occur on the client side with JavaScript. Now whether or not the user has JavaScript on there needs to be a mechanism to inform the user that an error has occurred. If JavaScript is turned off, then the form will start to submit, and the error will be caught on the backend, at which point the page will redraw with an error message. The screen reader can easily read this message. Since users with disabilities often have JavaScript turned off this server side solution is useful.

But if JavaScript is turned on, and an error is found, the page will not redraw. But rather JavaScript will display text that was hitherto hidden. Screen readers can pick up this text and read it. The site JuicyStudio has a good article on accessible form error handling.

Skipping to Content and Content Ordering

Most sites have a top and/or left navigation bar. This means that users of screen readers must listen to potentially dozens or hundreds of links on every page. Sighted users who rely on a keyboard have to tab through all these links if there is a form or link in the main content area that they wish to use.

A link should be provided for these users to go straight to the main content. This is simply an anchor that points to a named anchor lower in the page. This anchor should be one of the first elements after the BODY element.

Developers wanting to benefit the users of screen readers will often use a CSS "off screen" class to hide the link from sighted users, since they deem the skip link to be unattractive. This does not, however, benefit the sighted user who relies on a keyboard. It is best to make the skip link visible or use CSS to make the link visible only on keyboard focus.

#toContent a, #toContent a:hover, #toContent a:visited {
  position: absolute; left: -10000px;  top: auto; width: 1px; height: 1px; overflow: hidden;
} 

#toContent a:active, #toContent a:focus { 
  position: static; width: auto; height: auto; 
}

As we said earlier, if you are going to use an off screen class, do not use the top property with a negative numeric value as is sometimes suggested if there is linkable text inside, since it may force the browser to scroll to the top. Setting the top property to "auto" ensures that the browser will position the content vertically at the original vertical position. Also note that setting the width or height to zero pixels may actually hide the text from screen readers.

Another method has more to do with design. Navigation can be placed on the right side of the page after all main content. But a clever use of CSS will let you keep a left navigation scheme. You can place the left navigation bar after the main content in the HTML source and use CSS to make it appear before the main content. Screen readers read content in the order in which it appears in the HTML document. This method improves SEO as well since main content is more prominent for indexing. As is often stated, good accessibly is good SEO. However, bear in mind that you want the page to appear coherent when CSS is turned off. So be careful that your HTML ordering is not too far off the norm.

Access Keys

A navigation scheme can be provided for users who navigate with a keyboard. A keystroke combination, which varies across browsers, can be assigned to certain key areas of the site. A table would then be provided for users to refer to. These keystroke combinations should use the numbers 0-9 rather than letters because letters are already assigned in browsers, and collisions will likely occur across different browsers. Letters should only be used if there are more than 10 access keys.

Simply add the accesskey attribute to any link you want to include. This needs to be done on every page where the access keys function since they will not be stored in memory. However, they only need be written once per page. That is to say, if you have four links on the page that have a link to the homepage, only one needs the accesskey attribute.

Note that many sites do not use access keys because the user would have to move back and forth to the access key table to refresh their minds about which key does what. Also, key combinations often conflict with OS key combinations. Unless the site is small, it might be a waste of time.

Tab Indexes

Browsers are programmed to proceed through links and forms in a logical pattern. However, there will be times when you need to override the default tabbing order. A good example of this is with a DHTML navigation scheme where hovering over a link opens a palette of sub links. When this palette is available, that is, turned on, you want the user to be able to tab through them. You do this by adding tab indexes.

<a href="#" tabindex="100">Men's Wear></a>
<a href="#" tabindex="200">Women's Wear></a>
<a href="#" tabindex="300">Children's Wear></a>
...
<a href="#" tabindex="101">Men's Active Wear</a>
<a href="#" tabindex="102">Men's Pants</a>
<a href="#" tabindex="103">Men's Shoes</a>
...
<a href="#" tabindex="201">Women's Active Wear</a>
<a href="#" tabindex="202">Women's Pants</a>
<a href="#" tabindex="203">Women's Shoes</a>
...
<a href="#" tabindex="301"> Children's Active Wear</a>
<a href="#" tabindex="302"> Children's Pants</a>
<a href="#" tabindex="303"> Children's Shoes</a>

The first grouping above is accessible ("viewable") by default, while the other three schemes are accessible only when their respective parents are hovered over. If the keyboard user tabs beginning at "Men's Wear", the tabbing will then proceed to "Women's Wear" and "Children's Wear". If, on the other hand, the user tabs to "Men's Wear" and then hits the "enter" (or "return") key, the sub menu will be accessible. If the user continues to tab, the three sub links of the Men's Wear menu will be accessed, and then back to "Women's Wear". The addition of the tab indexes ensures that submenus can be navigated by the keyboard once they are made accessible by user intervention.

It is best to leave gaps between the main links to allow room to add more sub links.

DHTML Layers vs. New Windows

Developers will sometimes set a linked page to open in a new browser window, especially if the link is to an external site. Similarly, supplemental pages, such as help pages, are often placed in popups. The problem with this is that it is not very polite to take control over a user's desktop. But beyond that, a user with or without disabilities can lose sight of an instance of the browser, especially if they have several applications open already. This is also true for tabbed browsing. Moreover, a user using a screen reader might not know that they have suddenly started navigating a new window, though some screen readers announce that a new window has opened. If a user does not know that a new window or tab has opened, they will likely be disturbed when they find that the back button does not work.

If you need supplemental information, it is generally best to use a layer—that is, content within a DIV element that is hidden until needed—rather than a popup. The layer is glued to the page for the sighted user, so that they will not lose site of the content. For the visually impaired user the information can be read by the screen reader as if it is simply on the page, which it technically is.

It might be argued that a layer requires JavaScript. While that is true, so does a popup. For that matter, opening a new instance of the browser "requires" JavaScript (if you are using XHTML and care about standards), because the target attribute that is used in an anchor to open a new window has been deprecated in favor of JavaScript. Opening a new window is after all an event. Just as styling should be in CSS, events should be triggered in JavaScript, but that is another topic.

Another solution is to link in a normal manner to supplemental information, and then provide a link back to the previous page. The problem that designers have with this method is that they often want to control the page flow, especially when a user is making a purchase. The concern is that a user might be distracted to leave the page flow and not make the purchase.

If you do decide to link to a new instance of the browser, by all means place some text next to the link (or an image with alt text) to inform the user that the link will spawn a new browser. As we stated above, some screen readers will notify automatically if a new instance of the browser is spawned, but it is good to make certain.

This, by the way, is a good example of bad usability impacting accessibility. The developer will not always be able to change a firm's practice of opening new windows.

Flash and Non Web Material

With the increased use of JavaScript and CSS (known as DHTML when used in tandem), many artful designs can be realized without resorting to Flash. An excellent JavaScript library to achieve such appealing animations is jQuery . As a result we are currently seeing far fewer sites built entirely in Flash. The useless splash screen in Flash that invites users to enter a site—that they are already in!—is fast becoming a thing of the past. This is a good thing because Flash is less accessible. Because of that it is best not to use Flash except in the following cases. Flash is still fine for embedding an advertisement sequence to attract the eye, usually reserved for the homepage of a site. In this case, captioning or alternative content is required. Flash is also fine in the case of a relatively new technology called sIFR , which allows developers to use non-Web fonts. Lastly, Flash is a good tool for online video as popularized by YouTube.

Because there are many persons who are hearing-impaired, all video should have captioning or a link to a separate transcript. Two captioning tools are MAGpie and HiCaption Studio.

Animations should be designed to avoid screen flicker with a frequency greater than 2 Hz and lower than 55 Hz, otherwise seizures may occur in some individuals.

All non-web documents should be indicated as such so that users can avoid launching a program, such as MS Word or Adobe Acrobat Reader. This accessibility problem here is not unlike that of opening new instances of the browser in that it takes control away from the user if they are not first warned. An icon with alt text should be sufficient to indicate that a link will launch such an application.