In making web pages accessible to users with disabilities, a number of disabilities must be considered - hearing, sight, cognitive, and motor skills impairments. This paper focuses on sight disability for several reasons. Hearing disabilities are only relevant to the small fraction of web pages that have sound. Designing for cognitive disabilities is more judgmental and blends into general design issues. Motor skills impairments (e.g. difficulty or inability to use a mouse) can be easily tested by web page creators. Within sight disability, we focus on blind and severely visually impaired people -- those who must rely on a screen reader (a program that reads a computer screen aloud) or Braille translator. Since judging the adequacy of a Braille translation would require a knowledge of Braille, we focus on accessibility for screen readers.
A screen reader is a computer program that reads what is displayed on a computer monitor screen in a computer generated voice. These programs function in conjunction with the application that displays content on the screen. Thus a screen reader for a web page works together with a browser such an Internet Explorer. The same screen reader will generally work with a variety of other common programs such as Microsoft Office. A visual reader of a web page need not start at the top of the web page and read everything on the web page. Because of this, and because aural comprehension rates are lower than visual comprehension rates, screen reader programs provide a variety of keyboard commands to control what items are read and the sequence of items read. For this reason, the accessibility of a web page depends not only on how a web page is coded, but also on the skill of the user.
Although by far the largest use of screen readers is among blind and severely visually impaired people, other screen reader applications exist -- for example, the use of a screen reader where looking at a screen isn't practical (e.g., driving a car). In this paper, we will focus on the JAWS screen reader, currently in version 4.51. The demo version of JAWS is available as a free 27MB download from www.freedomscientific.com. The demo version is a fully functional version of JAWS, except that one must reboot your computer if using it for more than forty minutes at a time. Another screen reader is IBM Home Page Reader (current version is 3.02), which is available as a free 30 day trial download. An example of the audio provided by a screen reader can be found at www.trainingcafe.com/macromedia/accessibility/introduction.asp?offset=5#
We highly recommend installing such a screen reader and using it to test the examples provided in this paper as well as other examples. However, we provide some audio and/or text versions of screen reader output for those unable to test examples with an actual screen reader. Although testing with a screen reader provides the ultimate test of accessibility (for accessibility issues pertaining to non-visual access to web pages), a quicker way to test for accessibility is to use software that analyzes the page and produces a report of problems. Bobby is perhaps the best known example of such software. Single pages can be analyzed for free by entering the URL at the Bobby web site at http://bobby.watchfire.com/bobby/html/en/index.jsp The purchased version of the program will spider through a site automatically and produce the report.
There is other software, in addition to Bobby, to test accessibility. There are two principal sets of guidelines for accessibility of web pages: Section 508 and the Web Accessibility Initiative of the World Wide Web Consortium (W3C):
Although the focus of this paper is on screen reader accessibility, the techniques have some implications for other kinds of disabilities. We offer two examples. First, consider those unable to use a mouse. Except in very rare cases, a user of a screen reader will not use a mouse to point at anything because getting it to point at the right thing would require an iterative process ('move up, move left, etc.) that would be too slow. Once the pointing aspect of a mouse is removed, all that is left is the clicking aspect, which can be handled just as well by the keyboard. Because web pages accessible to a screen reader thus need not rely on mouse point-and-click functionality, they will be accessible to those unable to use a mouse. In some cases, this might require the use of an additional program that enhances the functionality of the keyboard beyond standard keyboard web page functionality. Second, techniques which avoid using color for directions (e.g. "Click the green button") for people unable to see a monitor at all also meet the needs of sighted, but colorblind people.
Last revised; May 19, 2003, prepared by William Pegram, wpegram@nvcc.edu