Accessibility Reference

Image Tests

Images, because they're visual, can obviously present serious obstacles to users who can't see. There is also some danger that a strobing image could trigger seizures in photo-epileptic users. The tests that are run on images are shown in Table A.2.

Table A.2. Accessibility Checks Performed on Images

A spacer image is one that serves only to lay out the page and doesn't contain any useful information itself. Most of these are blank or transparent images. Any purely decorative image such as a spacer image should have an alt attribute value of alt="" .

In the preceding table, some of these seem to be repeated with just a subtle change; for example, "Non spacer IMG with valid ALT" and "Non spacer IMG with equivalent ALT." A valid alt attribute is simply one that exists. If you leave off the alt attribute and give no value at all, it's not valid.

However, a valid alt attribute is not necessarily an equivalent alt attribute. Consider the top banner, which contained the text "Vote for President Littletree." If the alt value was alt="Vote" , this would be a valid alt attribute, but it would not be an equivalent value.

An automatic program, such as the accessibility checker in Dreamweaver MX, can check to see if an alt attribute is valid—but only human judgment can determine if the value is equivalent. For this reason, there is a manual check that goes with some automatic checks. The longdesc attribute is another example—only a human can determine if there's additional information needed to convey the image content.

CAUTION

You may begin to think that images are the enemy of accessibility, and should be avoided. Nothing could be further from the truth! Images, when given appropriate alt and longdesc attributes, are not an accessibility problem. In fact, lack of images may introduce accessibility hurdles for some people, including those with problems reading because of cognitive disabilities . A good illustration really is worth a thousand words, so don't be afraid to use images—be afraid to not use them!

Imagemap Tests

Imagemaps share all the possible pitfalls that could accompany images and introduce several potential problems of their own. The special checks done on imagemaps are shown in Table A.3.

Table A.3. Accessibility Checks Performed on Imagemaps

There are two types of imagemaps in HTML—client-side imagemaps that use <area> tags to define shapes , and server-side imagemaps that require a CGI script to determine the outcome of a map click.

Of the two, client-side maps are much more accessible because assistive technology programs can read the <area> tags and create a menu instead of an image with hotspots. However, each <area> must be marked with an appropriate alt attribute.

Server-side imagemaps present serious accessibility problems for users who can't see images, and thus whenever possible, they shouldn't be used. If you do use a server-side image map, you should make sure to provide equivalent text links for every hotspot on the imagemap.

Color and Style Tests

As shown in the campaign page example, the use of color can create accessibility problems when used carelessly. Contrast is important as well; blue links on light blue backgrounds are hard to see. Style sheets are almost always visual and may have many of the same problems as color when used to convey specific information. The checks for color and style sheets are shown on Table A.4.

Table A.4. Accessibility Checks Related to Colors and Style Sheets

Please keep in mind that neither of these are saying "don't use color" or "don't use CSS." In fact, you most assuredly should use both of them and use them regularly—color provides many usability and comprehension benefits, and style sheets are a boon to accessibility. These tests merely ask you to ensure that the vital information of the page isn't shown only in a style or color choice and is shown on the page in some other manner.

Form and Scripting Tests

Forms and scripts can present problems to assistive technology programs such as screenreaders. The checks done for forms and scripts are shown in Table A.5.

Table A.5. Accessibility Checks for Forms and Scripts

The requirement for <input> tags to have alt attributes applies only to image Submit buttons —those <input> tags with type="image" .

Scripts that have an effect such as presenting new content should have an equivalent <noscript> tag that either provides access to the content or links to a page or server-side program that has the same effect. Scripts that validate input or produce cosmetic effects such as mouseovers aren't required to have <noscript> tags.

Links that are purely JavaScript actions—or pull-down menus that change the current location without a Submit button being pressed—can be very difficult for assistive technologies and should be avoided. Also, pages that autorefresh based on <meta> tags can disrupt screenreaders; instead, use HTTP redirects in the server configuration or .htaccess file.

Table and Frame Tests

Tables and frames are very visual ways of presenting content in specific locations. When used injudiciously, they can introduce serious accessibility errors for people with visual disabilities, who may not be able to see the page at all or who may be using a screen magnifier and can't see the entire layout at once. The tests for tables and frames are listed in Table A.6.

Table A.6. Accessibility Checks Performed on Tables and Frames

The tests listed for tables apply to data tables —tables that have been inserted to display tabular columns of information, such as a bus schedule. Web accessibility standards distinguish between data tables and layout tables, which are tables used to lay out Web pages in two dimensions on the screen. Only data tables require special coding for headers, and then only when the table is complex.

Frames that have title attributes can be identified by the browser by name . As mentioned earlier, a title attribute is meant to be a human-understandable name, such as title="Navigation Frame" or title="Banner Ad Frame" . Avoid naming your tables by their location; alt="Left Frame" is useless because it doesn't describe the function, just the location.

WARNING

Should you even use tables and frames for layout? Tables used to be a more serious accessibility problem when screenreaders would read across line by line, cutting cells in strange places. Current screenreaders have improved this, and all you have to do is make sure that your table cells make sense when read in the order they appear in the source code.

Frames are more problematic —apart from potential accessibility hurdles, frames can introduce problems with bookmarking and usability. However, if labeled correctly, and if an appropriate <noframes> element is provided, frames can be made accessible as well.

This doesn't mean that they're the best solution—often, a non-framed design with CSS for layout can accomplish as much as tables or frames and has even greater accessibility. Use tables and frames with care, if you decide to use them.

Multimedia and Applet Tests

Multimedia, as used here, refers both to video and audio; embedded objects can include Java applets, Flash animations, and more. The tests for these types of content are shown in Table A.7.

Table A.7. Accessibility Checks for Multimedia Files and Applets

In general, the easiest way to deal with multimedia is to provide a text transcript of the information. In addition to the dialog, action and events must be described as well. A synchronized alternative is a text or audio version that plays at the same time as the video, such as a caption or an audio description. The synchronization is usually accomplished by using the Synchronized Multimedia Integration Language (SMIL).

TIP

To learn more about SMIL, visit the W3C's multimedia page at http://www.w3.org/AudioVideo/ on the Web.

Other Accessibility Tests

Several other accessibility checks that are performed don't fall into separate categories, but nevertheless are very important for ensuring the accessibility of your site. These are shown in Table A.8.

Table A.8. Additional Accessibility Checks Performed by Dreamweaver MX

Repetitive links are the pet peeves of many screenreader users. When a visual browser loads a Web page, a sighted user can instantly scan it in a glance, jumping to the content—usually in the middle of the page—and ignoring the navigation bars. Screenreader users don't have this luxury; they have to listen to all the links, on every page, again and again before reaching the content. For this reason, the Web accessibility standards suggest a Skip Navigation link at the top of the page that will take the user directly to the main content, bypassing the navigation bars.

In accessibility standards terminology, a natural language is any language that a human being speaks or writes . When part of a page is written in a different language, this could confuse screenreaders or automatic translation software; therefore, changes in natural language should be shown in the HTML tags. Use the lang attribute (and xml:lang in XHTML) to indicate changes in language, such as this:

<p>I counted to three: 
  <span lang="es">Uno, dos, tres.</span>
</p>

If you've tried everything and you can't make a Web page accessible, you can make an equivalent page that is simpler and presents the same information in straightforward markup and language. This is often called a "text-only page," but in general, a text page isn't necessary! Nearly any page can be made accessible by adding a few extra tags and attributes.