DESIGNING WORLD WIDE WEB PAGES FOR MAXIMUM ACCESSIBILITY

Jane Berliss, Computer Access Specialist, InfoUse
Wendy Chisholm, Researcher/Developer, Trace R & D Center
David Clark, Technology Specialist, CAST

Web Posted on: November 22, 1997

ABSTRACT

This paper summarizes the work of three organizations that have initiatives to help Web page designers enhance accessibility of their sites for users with visual and other types of disabilities. Today, there are accessibility guidelines for graphics and page layouts; there is also a Web site that verify Web pages' accessibility and compatibility with current browsers. Since new multimedia technologies, such as Java, are constantly being developed to bring new capabilities to Web sites, and since browser and server technology is evolving as well, this paper also looks into the role future technology may hold in making the Web maximally accessible to all users, regardless of disability.

USE OF TEXT AS AN ALTERNATIVE TO GRAPHICS

It is easy to assume that making Web pages accessible for people who cannot see the screen involves minimal, if any, use of graphics for maximum compatibility with screen readers. However, this is a severe oversimplification. Many people whose blindness is not congenital are still "visually" oriented and can use graphic elements to understand the organization of a page.(1) In addition, as will be discussed later in this paper, the number of people with non-visual disabilities for whom Web page graphics are an accessibility feature is also significant. The issue, then, is not to eliminate graphics, but instead to present meaningful alternatives that convey equivalent information to blind and non-blind users as much as possible.

Graphics on Web pages generally fall into one of three categories:

• Decorative - These are graphics that have no intrinsic meaning but provide an aesthetic touch and may also provide some organization to the Web page. Example: lines that separate sections of a page from each other.
• Illustrative - These are graphics that convey some information that is not essential to understanding the overall Web site. Example: a photograph of a company president.
• Integral - These are graphics whose content is key to understanding the overall site. Example: a chart whose contents are referred to without further explanation (e.g., "See Figure 1 for statistical information"). Image maps also fall into this category.

Graphics in the first two categories can be handled in HTML by using a two- or three-word ALT tag as part of an IMG tag. (2) These tags describe the graphic but do not detail its contents. For example, an illustrative photograph of a company president might have the tag ALT="Photo: Company President"; in almost all instances, it would not be necessary to describe her glasses, her outfit, her facial expression, etc. ALT tags can also be used as an alternative to integral graphics that are simply bit-mapped text.

Most integral graphics, however, are more complicated. These are handled in one of two ways: through D-tags or through text-only versions of the site.

D-tags is the letter "D" used as a link in close proximity to a graphic. Clicking on this link takes the user to a detailed description of the graphic; this description then has a link back to the original page.

Text-only site versions echo the entire original site in a format that uses only text and text descriptions of graphics. While this is more complex to set up and maintain than using D-tags, it may be easier for blind people to use this text-only version if the site contains a large number of integral graphics.

OPTIMIZING PAGE LAYOUT FOR BLIND USERS

While ALT-text and D-tags are important in making graphics more accessible, graphics and other structures can be used to make the layout and therefore the content of Web pages more easily understood by blind users. The following are examples of factors that can enhance accessibility:

Text anchors and punctuation

After the end anchor tag, include a couple of spaces. This prevents screen readers from reading a list of links as one link and making it difficult to select the links within the list.

Lists

Before each list, give an indication of how many items are in a list. This is especially useful for lists that are numbered, because the user can more easily keep track of where they are in the list.

Use some sort of bullet for each list item. When a list item is longer than one line and there is no indication where the list items begin, the second line of the item might be perceived as a new item. Numbers usually make it easier to keep track of how long the list is and where in the list you are, but this sometimes implies an erroneous ordering of the items. The default bullet that is generated with HTML is usually identifiable by screen readers. If using a graphical bullet, refer to the previous discussion on ALT-text.

Tables

Since tables can be used for several types of layouts, at this point in time the only general principle is to be careful in the design of tables. If you cannot read across a line without confusion, create a text-only version of the information within the table. Trace's Web site contains some case studies using table layouts to make them more accessible to people using screen readers, such as a one-month calendar. This case study will change as screen readers are able to read by columns (and tests are performed with current screen readers with this ability). However, there will still be the basic need of being able to query which column or row you are reading. Innovations in HTML and browser design could allow users to more easily interpret tables.

Another option is to include a Java script that breaks the table into text. This needs to be tested, and would need to be implemented by the page designer.

Future Innovations

Wendy Chisholm is currently developing a master's thesis that tests how auditory cues can help in the understanding of page layout and page content. The use of musical and spatial cues to represent attributes of layout and text may help non-sighted users to gain a better and quicker understanding of what is going on than is currently possible.

OPTIMIZING PAGE LAYOUT FOR USERS WITH PHYSICAL AND/OR COGNITIVE DISABILITIES

Links

Major links (e.g., links that provide navigation among pages within the site) should be placed or echoed at edges of the screen, usually the top or bottom. This facilitates access by people who have difficulty using the mouse or use a mouse alternative. All links should be as large as possible; e.g., instead of "Click here to learn about deep-sea diving," the link should be "Click here to learn about deep-sea diving."

Consistency

As much as possible, keep elements that appear in identical or similar forms on multiple pages (e.g., a "Go On" button) in the same location on each page.

Use of Organizing Graphics

As mentioned above, decorative graphics can be used to provide organization to the page. This can be through providing separation between elements, associating similar elements with a common graphic symbol, etc. This will help people in general, and particularly people with cognitive disabilities, to understand the page setup with minimum effort.

Future Innovations

In the future, servers and browsers may play a greater role in providing access. Browsers may include innovations such as the capability of automatically jumping from one link to the next. Users could be able to set preferences at the server level, as they are now able to do to some extent in the browser level.

ENHANCING ACCESS TO MULTIMEDIA

Video

WGBH/NCAM is developing methods for access to movies and graphics, including the previously mentioned D-tag concept for graphics. They are also working on guidelines for inclusion of captioning and audio descriptions in video files. Their Web site is at http://www.boston.com/wgbh/pages/access/accessinstructions.html.

Audio

Transcripts of speech in audio files and descriptions of audio events should accompany all links to audio files. WGBH suggests using the word "Transcript" under the name of an audio file as a link to a transcription.

Java

The Trace Center has been working with Sun Microsystems to create a set of recommendations on including or creating constructs to make Java applets and applications that are more accessible. (See the paper on "Creating Java for Everyone" elsewhere in these Proceedings.). The main ideas are to utilize built-in controls whenever possible and minimize creation of child windows from your applet/application (this includes objects that create windows, such as Choice). Until assistive technologies and Java applets/applications work better together, it is often advised to offer functionality by other means.

USING BOBBY

One way to see if your web pages adhere to accessibility guidelines is to run them through a Web site called Bobby. Bobby was designed by CAST to detect a wide variety of accessibility problems commonly found on Web pages. Bobby uses a broad definition of accessibility, citing not only errors that hinder access to people with disabilities but also tags that do not work on particular browsers. Thus, a paged checked by Bobby is assured to be accessible to the broadest audience possible.

The Bobby Web site (http://www.cast.org/bobby) is very easy to use. The page has some basic information on Bobby and CAST, and a field for entering a URL. (Users who cannot use forms may Email their page to bobby@cast.org.) After entering in the URL of the page you want it to analyze, Bobby will redisplay an annotated version of the original page. At every place where there is a disability access problem, there will be a small disability access violation symbol followed by a letter and a number (like E1 for Error 1). Browser compatibility problem display a miniature Bobby icon on the annotated page. Clicking on either type of access violation symbol will display a description of the error. Bobby places all these descriptions at the end of the annotated document; you can see them all at once by dragging your browser's vertical slider bar to the bottom of the annotated Web page. If the error message seems confusing, just click on it (it is a hypertext link) and a more detailed description will be displayed along with possible solutions to the problem.

Bobby's error messages are divide into three main categories: errors, warnings, and suggestions. An error is a problem that would cause a page to be inaccessible to many people and is often something that is important to fix. A warning usually means an access problem that should be fixed, but doing so could substantially limit the designer's choices (e.g., not using HTML Tables). And finally, a suggestion is Bobby's way of telling you that there might be something you want to consider adding or changing on your web page, but it is not imperative to the page's accessibility.

Below is a list of all the errors, warnings, and suggestions that Bobby is capable of displaying.

Errors

Missing ALT text for image

Missing ALT text for image map hot-spot

Missing ALT text for Java Applet

Web page takes longer than 1 minute to download using a 14.4Kb modem

Adjacent hypertext anchors must be separated by more than a new line

Invalid attribute error

Invalid attribute assignment error

Invalid element error

Client-side image map: XXX contains a hypertext link: YYY which is only accessible through the image map

Link name contains ambiguous phrase (i.e. click this)

BLINK and MARQUEE tags cannot be read by screen readers.

Audio and Video files should be followed by a download size

Use both server and client side image maps

AREA tag occurs outside a MAP definition

Too many words in link text

Client-side image map: XXX is not defined

Missing NAME attribute for client-side image map

Missing SRC attribute for IMG tag

No server-side image map specified even though ISMAP is used

Client-side-pull makes pages inaccessible to screen readers

Warnings

HTML FORMs are not accessible without a mouse for the browsers

Background images can sometimes make pages unreadable

Within word font changes confuse screen readers

Smileys :) or ;) are troublesome for screen readers :(

HTML tables are often incorrectly read by screen readers

Too many words in ALT text

Suggestions

No text-only link found. You might need to add a text-only version of this web page.

Movie file requires descriptive text

Audio files requires descriptive text

REFERENCES

(1) Richards, Jan. Guide to Accessible HTML: HyperText Mark-up Language. Formerly at World Wide Web page http://www.utirc.utoronto.ca/AdTech/rd/html/html.html

(2) For a more detailed technical discussion of implementing ALT tags, see Fontaine, Paul. Writing Accessible HTML Documents. World Wide Web page http://www.gsa.gov/coca/WWWcode.htm

BIBLIOGRAPHY

Berliss, Jane, Kraus, Lewis, and Stoddard, Susan. Design of Accessible Web Pages. World Wide Web page http://www.infouse.com/disabilitydata/guidelines.html

DO-IT HTML Guidelines. World Wide Web page http://weber.u.washington.edu/~doit/Other/design.html

University of Toronto Adaptive Technology Resource Centre. World Wide Web page http://www.utoronto.ca/atrc/welcomesr.html

Vanderheiden, Gregg. Design of HTML (Mosaic) Pages to Increase their Accessibility to Users with Disabilities. Version 1.1, April 2, 1995. Available on the CONET 8 CD-ROM from Trace Research and Development Center, 1500 Highland Ave., Madison, WI 53705, or at the Trace web site http://trace.wisc.edu/

WebABLE! World Wide Web page http://www.yuri.org/webable/index.html