Page 2 of 3   « previous page   next page »

For example, an existing form tag might have been inserted between a table tag and a table row <tr> tag. Although this is structurally wrong and should be avoided, it still works in common browsers, so you might already be using it.

<table>
<form name="form1">
  <tr>
     <td><input type="text"
      name="text1" /><input
      type="submit" name="sub1" />
  </tr>
  </form>
</table>

Experience has shown that cleanup tools often take liberties when reorganizing form tags, effectively removing tag information that you expect to be part of the form:

<table>
  <tr>
     <td><form name="form1"></
      form><input type="text"
      name="text1" /><input
      type="submit" name="sub1" />
  </tr>
</table>

This will render a button that does not react when clicked. It is recommended that you move the <form> tags outside the <table> tag altogether. This example also illustrates why you should conduct a functional regression test after making accessibility changes, even though they are largely considered to be "cosmetic" rather than functional.

Another area within forms to consider is the use of labels. Labels are generally located close to the entry field (on top of, or to the immediate left of), but that does not guarantee assistive technology will associate it with a particular form element. Use the <label for="id"> element to specify the association between the label and the entry field.

Images Need Alternative Text
Images need text alternatives in the form of ALT attribute or LONGDESC attribute (for longer text) to describe their content in order for reader software to convey their message to users. This is particularly important if the image is a diagram with information content such as figures, pie-charts, etc. That information must be conveyed in a different format as well.

Image Maps Need Alternative Text
Consider a dynamic image map such as a U.S. map of all 50 states in which you can access information for any state by clicking on, or hovering over the state (representing an image hot spot) with the mouse (see Figure 5).

An accessible version of this would need to convey the same level of information for the top-level image, such as the color schemes and what they indicate. It must also address how to navigate to each state via the keyboard.

Accessible Alternatives for JavaScript
The preceeding example included hover-over popups for image maps. As hover-over popups, info boxes, and flyover menus become more common on Web sites, care must be taken to ensure that there is an accessible equivalent for the navigation and information delivery functionality. Flyovers are usually implemented using JavaScript which is not accessible by default. Turn off JavaScript and test the page again to get a better feel for the dependencies, and then limit these as much as possible. Also test the page's functionality in keyboard-only mode.

Easy Navigation and Shortcuts
Many Web sites include a header and left-navigation section, allowing users to use links to jump directly to the page contents section.

The jump links can be achieved by creating a hyperlink and associating it with a one-pixel sized image that has alternative text.

<a href="#main">
<img src="pixel.gif" height="1" width="1" 
border="0" alt="Jump
 directly to main section" /></a>
...
<!-jump to here -->
<a name="main"></a>

In case a Web site is using frames to differentiate the screen sections, each frame should have a title in order to improve the ease of navigation among them.

Alternatives for Multimedia Content
Multimedia content generally requires third-party utilities and is rarely accessible; therefore, you must provide accessible enhancements such as captions, visual queues for audio alerts, and volume controls. If enhancements such as these are not possible, you must provide an accessible alternative, for example, a text-only transcript.

Explanatory Text for Web Pages
Consider a Web page that contains a table with sales figures per sales quarter.

In order to understand the numbers presented in any given data field (such as "$160"), the user visually checks the row header on the left, such as "Apples," and then the column header above, such as "2003/Q3." With an HTML reader users cannot perform the same correlations for that data since it is presented in a predominantly linear manner, word for word, as text.

Figure 6 shows how users with unimpaired vision can assume a birds-eye view and have the capability to refocus on special details, shift visual focus to jump around and correlate information, or drill down into other sections. This is very difficult with a reader, therefore special provisions are needed.

A basic technique is to provide explanatory text using a zero-sized image with ALT text. The ALT text will only be presented to the reader software, not to someone viewing the page using a normal browser.

<img src="pixel.gif" height="1" width="1" border="0" alt="Sales of Apples for Q3/2003" />

The example also includes three radio buttons: Details/Edit/Delete. If the radio buttons are not annotated for reader software, the values would be read without the description, such as:

Checked
Unchecked
Unchecked

Page 2 of 3   « previous page   next page »