A Column by Andy Anderson and Susi Knoer
Special Collections, Ekstrom Library

For the World Wide Web to be truly worldwide, it must be accessible to all users, including those with low-tech equipment and those with disabilities. Some disabilities require accommodations at the point of use, but many problems and "work arounds" can be eliminated at the source by creating the most accessible page from day one. This isn't just being a good neighbor, it's also required by law under The Americans With Disabilities Act.

The Web is a graphics-intensive environment today, and can be a frustrating one to someone using a text-based browser and a screen reader. Try turning off the graphics preference of your browser and see what happens. Graphic buttons can render a page unnavigable and unintelligible. A text-only alternative using the tag can supply the same information. A well-done alternative description can make content available for all users. A good model for such descriptions is http://www.inf.fu-berlin.de/~kurze/publications/se_95/swerg95.htm. It's also a nice model for point-of-service use within the library.

Banners and bitmapped text look like type but are really individual graphic units which are unreadable by screen reader. Adobe's popular PDF format is strictly graphic (that's why it takes so long to download), and while it does have an accessibility patch available, it's still slow. And proprietary formats, such as major word processing programs require the user to have the same software to view them.

Netscape's blink tag is more than just annoying to users of screen readers, it can make the blinking text disappear or even freeze speech systems. Since screen readers read a full line of text horizontally, they cannot interpret multi-column formats or cells in spreadsheets and tables.

The excessive amounts of code imbedded in web documents by the newer, visual HTML editors is a problem since most screen readers don't recognize HTML source code, and will read code to you one symbol at a time along with the text. If you have access to a Mac with OS8, load a page with HTML into the Simple Text screen reader that comes with it, and see how the code interferes with the content of the site.

As the final step in preparation of any web page, you should pay a visit to Bobby, a website which checks your HTML code and lets you pick different browsers and gives a rating of accessibility for the page. The URL is http://www.cast.org/bobby/. Set the page for Lynx 2.7 and text only, then enter the URL for the page you want to check. The U of L homepage at http://www.louisville.edu is a good example of the problems of bitmapped images and links. A search engine should help you find good sites, but look at Alta Vista through Bobby: http://altavista.digital.com.

For more on writing accessible code, look at "Writing Accessible HTML Documents" at http://www.yuri.org/webable/htmlcode.html and "Unified Web Site Accessibility Guidelines" at http://www.trace.wisc.edu/text/guidelns/htmlgide/htmlgide.htm.

So do you have to give up all your fun toys on the Web? No, just remember that all users can't or don't want them, and provide a text alternative. There can even be fun ways to address the problems. One idea is to give a "glimpse" of a graph by giving the rise and fall as tones. If there's more than one line, each gets a different instrument. Music by the numbers, literally.

Remember, a disability is a personal limitation. A handicap is the barrier imposed by the environment. Our mission as a university is to serve not only our current users, but also those who have been hindered or discouraged by these barriers, or those who may not even know of our existence because we have not addressed them in an accessible manner.