Because the World Wide Web (WWW) has rapidly advanced from a text-based communication format to a graphical format embracing audio and video clip tools, persons with disabilities cannot navigate web sites unless web pages are designed in an accessible format. Just as curbcuts enable persons using wheelchairs to navigate a city, electronic curbcuts enable persons with hearing, visual and learning disabilities to navigate your web page.

For example, a person with a hearing disability cannot hear a video clip if it is not captioned. Similarly, a person with visual and learning disabilities cannot navigate a web page incompatible with text browsers and screen readers. Graphics are inaccessible to text browsers and screen readers which audibly read web site text. Without special coding, the text browsers only display the word "image" when it reads a graphic image. For this reason it can be incredibly frustrating to know there is an image or a link but not to be able to obtain any information on what it is. Even worse, if the graphic is essential to navigating the site (such as a navigational button or arrow) or if it imparts vital information (such as a table) the user can get stuck and not be able to move or understand the information provided. As one user put it:

"When blind people use the internet and come across unfriendly sites, we aren't surfing, we are crawling... Imagine hearing pages that say, "Welcome to ... [image].' 'This is he home of ... [image].' 'Link, link, link.' It is like trying to use Netscape with your monitor off and the mouse unplugged. See how far you will get."

(New York Times Cybertimes, 12/1/96, www.nytimes.com/library/cyber/week/1202blind.html)

The Need for Disability Access Design Standards

By Executive order dated September 15, 1993, President Clinton established the United States Advisory Council on the National Information Infrastructure (NII). Since that time, the NII has moved forward to develop fundamental priciples for building the information superhighway to allow "all Americans to take advantage of our rich resources in information, communication and computing technologies." (See: "Common Ground: Fundamental Principles for the National Information Infrastructure," First Report of the National Information Infrastructure Advisory Council, March 1995.) In September 1994 NII published a White Paper entitled "People with Disabilities and the NII: Breaking Down Barriers, Building Choice." In March 1995 seven Universal Access and Universal Services Principles were adopted by the NII. Principle five states:

"Individuals with disabilities should have access to the NII and, therefore, design issues should be addressed as the NII is developed to ensure access for individuals with disabilities."

Currently, Universal Design Standards are not fixed and have been evolving as part of the efforts of the NII. Specifically, Universal Design calls for the development of information systems flexible enough to accommodate the needs and preferences of the broadest range of computer and telecommunications users, regardless of age or disability. Certain features of Universal Design are evolving in the internet community to ensure electronic curbcuts.

There are also significant legal reasons for being sure that the university campus web page is accessible. By failing to provide access to the internet, universities have been found in violation of Section 504 of the Rehabilitation Act of 1973 and Title II of the Americans with Disabilities Act of 1990.

This past year the Office of Civil Rights (OCR), United States Department of Education, has discussed in their settlement letters the need for educational institutions to reconsider the practice of providing personal reader attendants as the exclusive or primary way of making web sites accessible to persons with disabilities. OCR has repeatedly expressed its concern about the "graphic window" commonly used on web pages that produces stumbling blocks when not encoded with ASCII-description. In a nutshell, OCR is not concerned about whether or not the student with a disability is merely provided access; OCR is concerned about whether or not the quality of that communication is as effective as that provided to other students without disabilities at the web site.

This article is a brief introduction to the building blocks or elements of an accessible website (Note: The reader may want to refer to the glossary of terms located at the end of this article.)

Solutions: How to Build an Accessible Site

Access can be improved at two levels: 1) by webmasters at the homepage design phase and 2) by the creators of adaptive technologies and internet browsers.

What can the "Webmaster" Do?

Web homepages are text documents written with specialized coding known as HTML (Hypertext Markup Language) which, when viewed by a browser such as Microsoft Explorer or Netscape Navigator, appear as beautifully-designed, colorful homepages complete with graphics, animation, audio and video. Each unique design feature in a homepage is created by a special HTML code interpreted by the browser. However, not all design features are viewable by every browser, especially text browsers, and screen readers cannot interpret sophisticated design layouts or special formats such as graphics, PDF files and video clips. Even audio is inaccessible to persons with hearing disabilities.

The Basis Rule

The basic rule for providing access to persons with disabilities is to provide HTML code that can be read by the access technology being used (including text-only browsers and screen readers) or, where that cannot be done, provide alternate text and descriptions. This is true for simple things such as buttons and horizontal lines as well as the latest in high tech audio and video. The good news is that it is not necessary for the design and presentation to suffer so long as the information is made available in an alternate format. One solution is to provide parallel text-only versions of the entire site or at least any pages that contain inaccessible code. Other strategies include:

A. Graphic Images and Image Maps

In the code defining the graphic, provide an alternate text description or name. This is commonly referred to as ALT-TEXT because it is introduced with the HTML tag ALT=. Most browsers now support this tag and web-authoring tools have an automatic prompt for this tag.

The text should be a short and simple description. Additionally, WGBH and the National Center for Accessible Media have pioneered the use of the capital "D" following an image for a link to a textual description of the image. In client-side image maps, using the ALT= tag to describe links in the areas within the map will provide sreen readers with descriptions of the links. (For examples of coding for alternate text, embedded text descriptions and image maps, see box insert at the end of this article.)

B. Navigation, Organization and Links

Web designers should remember that viewers may have to (or because of slow modems choose to) visit their page without seeing any graphics at all. Designers should avoid using color-coding or graphics (such as buttons or an image map) as the sole way of imparting important navigational information. Links should contain language more descriptive than simply "click here" or "here" or "new" for browsers that view or gather only the links. Page organization should be simple and consistent; navigational buttons should appear in the same place on each page. Colors and backgrounds should be kept to a minimum and provide the highest contrast for low vision users. Generally, non-standard code or browser specific features such as tables, columns, blink, frames and forms cannot be viewed and used by all browsers and they should be avoided for now. But software developers are working to solve this problem.

What the Software Developers Doing to Help

ADOBE ACCESS is a software program currently being beta tested by Adobe Systems to correct the inability of screen readers to read web pages created by their popular program called Adobe Acrobat. Web documents created by Adobe Acrobat use PDF or "portable document format" and are not accessible to screen readers because the text page is in a graphic format. ADOBE ACCESS software attempts to access simple PDF documents but cannot access certain complex PDF documents. The current beta version creates an alternate view of the document in a separate window and, using the "Enhanced Reading Order" feature, attepts to present the text in reading order for screen readers by interpreting the logical structure and layout of the original document.

(Author's note: However, even if you have a PDF document on your web page, all web visitors must use Adobe Acrobat Reader to view the document. If the web visitor requires a sceen reader, then both Acrobat Reader and ADOBE ACCESS will be needed and these extra steps have a negative impact on the accessibility of your web page.)

INTERNET EXPLORER has accessibility features that Microsoft has also begun to incorporate including keyboard navigation (for those who cannot use a mouse), large font options and high contrast settings. Explorer also supports the ALT= tag and goes even one step further; whenever an ALT= tag is used to explain a graphic image, Explorer will display the alternate text, called ALT-TEXT, in a pop-up window on the screen.

pwWEBSPEAK by The Productivity Works, Inc., is a new "nonvisual" browser especialy designed for persons with visual disabilities. The unique feature of pwWebSpeak is that it directly interprets the HTML code underlying each page (rather than reading the screen). It also recognizes links, interfaces with web search engines, audio, video, forms and image maps. Eventually it will support frames, voice command control and refreshable Braille displays. http://www.prodworks.com

BOBBY is a project from CAST, the Center for Applied Special Technology, that acts as a diagnostic enter for homepages at: http://www.cast.org/bobby/. Bobby will analyze your webpage; diagnosing any inaccessible codes and offering suggestions.

PANORAMA is under development by SoftQuad and is designed to create a software browsing "Accessibility Toolkit" to supplement existing browsers and better integrate alternative access features such as screen readers, screen mangnification and on-screen dynamic keyboards (rather than mouse control). http://www.utoronto.ca/atrc/rd/panorama/panorama.html

Resources Available

There are many great sites on webpage design, some with complete "how to" guides on HTML code and the latest developments. Here are a few to look at:

California Homepage: ACCESS FOR ALL! http://www.ca.gov/access/howtoweb.html

Center on Information Technology Accomodation and the NII: "http://www.gsa.gov/coca/nii.htm

City of San Jose Web Page Disability Access Design Standards: http://www.ipac.net/csj

DOIT Site: (Disabilities, Opportunities, internetworking & Technology at UW) http://weber.u.washington.edu/~doit

Design Guidelines: http://weber.u.washington.edu/~doit/Other/design.htm

Environment Canada Adaptive Computer Technology Centre Site: http://www.igs.net/~starling/acc/index.htm

InfoUse Project of the National Institute on Disability & Rehabilitation Research Site: http://www.infouse.com/disabilitydata

Design of Accessible Web Pages by Berlis, et al. http://www.infouse.com/disabilitydata/guidelines.html

Trace Research & Development Center, University of Wisconsin-Madison Site: http://www.trace.wisc.edu

Design of HTML Pages to Increase their Accessibility to Users with Disabilities, by Gregg C. Vanderhelden et al. http://www.trace.wisc.edu/text/guidelns/htmlgide/htmlgide.txt

UCLA Disabilities and Computing Program: http://www.dcp.ucla.edu

WGBH National Center for Adpative Media Site Access Instructions for Users with Disabilities: http://www.boston.com/wgbh/pages/access/accessinstructions.html

NCAM (National Center for Accessible Media Information http://www.boston.com/wgbh/pages/ncam/ncamhome.html

Yuri Rubinsky Insight Foundation WebABLE Site www.yuri.org/webable/index.html

People with Disabilities Can't Access the Web, January 1997 by Mike Paciello http://www.yuri.org/webable/mp-pwdca.html

Writing Accessible HTML Documents, by Paul Fontaine http://www.yuri.org/webable/htmlcode.html

Information on Product development

Bobby: http://www.cast.org/bobby/

Panorama: http://www.utoronto.ca/atrc/rd/panorama/panorama.html

Microsoft: http://www.microsoft.com/le/most/howto/access.htm

Examples of Accessible Code

ALTERNATE TEXT (ALT=)

The screen reader will tell the user that thre is a graphic of a fish. This works for graphics that appear right on the html page (called inline images).

EMBEDDED TEXT DESCRIPTIONS

Accessible Code looks like this:

Your text here <A HREF="./coolgraphics/graphic.gif">
<IMG SRC="./coolgraphics/graphic.gif" ALT="graphic of --- ">
more text which actually makes the graphic redundant
so that if it isn't there its ok.</a>

IMAGE MAPS

Accessible Code looks like:

Glossary of Terms

Graphic Image: A picture or button icon that is not text

HTML: Hypertext Markup Language is a programming language for creating web pages.

PDF: Portable Document Format is the format of Adobe Acrobat documents. The format displays text documents in a graphic format that cannot be read by a screen reader used by persons with disabilities because screen readers require characters.

Refreshable Braille: Enables a person who is blind to read text on a computer screen; by attaching a Braille terminal and using appropriate software, text is translated to Braille on a tactile keyboard.

Screen Reader: A program that audibly reads the text on a computer screen that provides access to a web site for a person with visual or specific learning disabilities.

Text Browser: A program that runs on an internet-connected computer that provides access to the World Wide Web. There are two kinds of web browsers: text-only and graphical. Text-only browsers do not show in-line images, fonts and document layouts.

Leslie M. Campbell is the Public Services Librarian at the University of San Francisco Law School Library and was formerly a web designer (and librarian) at Heafey Law Library, University of Santa Clara School of Law. She has a JD from University of California, Boalt Hall and a MS from the University of Washington.

Cynthia D. Waddell is the ADA Coordinator for the City of San Jose and the ADA/504 Compliance Consultant for the University of Santa Clara. Her development of Web Page Disability Access Design Standards brought federal recognition and caused the city to be featured in the President's 1997 Inauguration activities. She holds federal, state and county appointments in disability access. She has a JD from the University of Santa Clara School of Law and a BA from the University of Southern California.

| Top of Page |

© Copyright 1999. Cynthia D. Waddell and Leslie M. Campbell. All rights reserved.

Return to Papers and Presentations

Electronic Curbcuts: How to Build an Accessible Web Site

By Leslie M. Campbell and Cynthia D. Waddell

Defining the Problem