Accessible Web Design - PAGE 3

"Technologically rich sites that feature multimedia are great. So long as the user can choose whether to use it or not."

Web Content Accessibility Guidelines (WCAG 1.0)

This is a collaborative international program of the W3C Web Access Initiative (WAI). The WCAG 1.0 are a stable document (still available) released in 1999. Notes and techniques are updated regularly to keep up to date with new technologies. Industry standards and policies are being developed that customize the WAI guidelines for particular industries (for example, banks need a stronger focus on the implications regarding online transactions).

There has only been 1 official court case that was subject to the Disability Discrimination Act 1992 in the Maguire vs. SOCOG case. When Maguire was unable to obtain information from the Olympic web site, SOCOG's attitude was 'too bad'. See the article Olympic Failure: A Case for Making the Web Accessible for more details.

The subject matter of a web site is not an excuse for inaccessibility. For example, a disabled person may not be able to drive a car, but what if they are trying to research what kind of car is suitable for their son or daughter? Most car manufacturers feature sophisticated flash web sites. These are fine if the user has an option to obtain the information in other ways. It is good business practice to provide resources that are usable and accessible, even if the target market are not disabled people.

For more information on WCAG 1.0, see the list of WCAG 1.0 guidelines on page 5.

The WCAG has complimentary guidelines for:

• Authoring Tools. Includes software developers.
• User Agents. Includes rendering devices such as browsers.

WCAG 2.0

WCAG 2.0 is still under development. It is aimed at simplifying WCAG and is less technically specific (for example, the sole focus will not be on html). WCAG 2.0 focuses on the following principals:

• Perceivability. More tuned to a users needs and preferences.
• Operable. Interaction should be operable by any user.
• Orientation / Navigation. Facilitates usage of these.
• Comprehensible. Easy to understand and use.
• Technologically Robust. Compatible and long term durable.

TOP

Good practice

Many of the strategies for accessible design apply to web design in general. Others are more specific. The designer needs to have a reasonably high level of coding competence. Take the following into consideration when dealing with download times:

• tell users the file sizes
• don't use "click here" or "more" for links as these have no contextual meaning, particularly when read from a screen reader.
• section and whole file options - broken logically
• PDFs for web are technically different to PDFs for print. Images and photos are usually responsible for dramatically enlarging the file size of a PDF. It may be a worthwhile consideraton to include a PDF that has no images or photographs.
• use properly compressed images
• don't use images unless they have a purpose (the cartoon image of the blind turtle isn't technically necessary for this article. It is there to add visual interest and attempt to balance out the serious nature of this content)
• thumbnails are often better than full size images
• crop unnecessary data from photos. Sometimes you can crop the thumbnail more dramatically than the full size image to give the user a larger preview. See the examples below:

This thumbnail has been cropped more than the photo so that the important part of the image is as large as possible

Here is the full size photo with extra detail.

• reuse cached images (e.g. the turtle cartoon in this article)
• use checking tools to help locate the offending elements
• specify width and height of images. This will provide a 'space' in the document for images while they download, thus preventing the text from re-flowing when the image fully loads
• separate tables for major sections. A user may think there is a problem with your site if there is an accessive wait for a large table to fully load. By that time they may have left.
• avoid nested tables - specially more than 2 deep. Tables render from the inside out.
• consider appropriate page lengths. This is a matter of common sense.
• mix https with http instead of rendering the entire page (non-secure areas) from https
• multimedia should be optional. Content is primary.
• consider appropriate levels of audio compression. (e.g. an audio clip that is spoken word only can be compressed significantly more than a recording of an orchestra.)
• sometimes it will save file size to splice images (see examples below)

This first image uses 2 slices. The fish is a JPG and the underwater scene on the right is a GIF. The total file size is 3.12 kb.

The second image is a single JPG. The total file size is 4.02 kb.

TOP

go to page 4 of 7