Accessibility: Design of Accessible Web Pages (1996)

Design of Accessible Web Pages

Jane Berliss
Lewis Kraus
Susan Stoddard

This document is funded in part by the project "An Internet Based Curriculum on Math and Aeronautics for Children with Physical Disabilities," supported by Cooperative Agreement #NCC2-9011 with NASA's High Performance Computing and Communications Office, a part of NASA's Information Infrastructure and Applications Program.

This document is funded in part by the project "Improving Access to Disability Data, a National Dissemination and Utilization Center," #133D50017 with the National Institute on Disability and Rehabilitation Research (NIDRR)

© InfoUse 1996
2560 Ninth Street, Suite 320
Berkeley, CA 94710
phone: (510) 549-6520
fax: (510) 549-6512
TTY: (510) 549-6523

Note: This document is also available in PDF format. By selecting this link, you will download the "Design of Accessible Web Pages" document for viewing and printing as it appears in its print version. To use this format, you will need to use Adobe Acrobat Reader, which is available from Adobe's download site.

TABLE OF CONTENTS

a. General Design
b. Buttons and Icons
c. Color and Pattern
d. Speech and Sound
e. Typefaces
f. Graphics

a. Movies
b. Links
c. Image Maps
d. Forms

Computer system design assumes use of several physical capabilities or combinations of capabilities-sight for viewing the monitor, manual dexterity for typing on the keyboard, and hand-eye coordination for using the mouse, etc. If a user lacks functionality of one or more of these capabilities, he or she will likely have difficulty using computers without some type of modification-software (e.g., software programs that provide screen magnification), hardware (e.g., alternatives to standard keyboards with highly touch-sensitive keys), or a combination of hardware and software.

With the advent of the Internet, new accessibility issues have arisen. The Internet combines graphics and text to deliver information faster and more efficiently than ever before. However, graphics are inaccessible to blind people and difficult to access for people who have low vision or low bandwidth. Web pages also frequently have clickable links to enable rapid movement from page to page, but these links may be small and difficult to access by people with a range of manual disabilities, including wrist disorders caused by computer use. In addition, Web technology is developing at an astonishing rate, making it difficult to anticipate trends in design of typesetting, browser, or server technology even a short distance into the future. The purpose of this document is to propose access solutions for at least current and foreseeable issues so that developers can create pages that will be as accessible as possible.

Three factors are involved in delivery of Web pages to end users; any of these may have accessibility features built in. The first factor, with which this document is primarily concerned, is the design of Web pages themselves. The second factor, which is discussed in Appendices 2 and 3, is the use of the browser to enhance accessibility: Appendix 2 lists some settings that can be used in today's browsers, while Appendix 3 outlines two of the several current initiatives on building accessibility features into future browsers.

This document is intended to convey guidelines rather than standards. We do not expect every guideline to be met or to be relevant for every Web page; rather, we anticipate that the guidelines will serve as a resource for identifying problems and finding solutions that make Web pages accessible to people with a variety of disabilities, both independent of and in tandem with various types of adaptive hardware and software.

In compiling this document, we have included the writings of many previous guideline developers, particularly the Trace Center (Madison, WI), the General Services Administration (Washington, DC) and the Mosaic Access Project of the National Center for Supercomputing Applications (NCSA) (Champaign, IL). The original documents should be consulted for clarification and expansion on any guideline that may generate questions for you. We would also like to express appreciation to Lisa Wahl of the Center for Accessible Technology (CforAT), Berkeley, CA for extensive and invaluable assistance.

Keep layouts simple and straightforward. (Vanderheiden, 1995)

Make language as simple and straightforward as possible on screen. (Vanderheiden, 1994)
-- Pages designed for screen readers should always be kept simple and concise since screen readers will read every word. (Richards)

Use consistent and predictable screen layouts. (Vanderheiden, 1994)

Screen elements (icons, text, buttons, etc.) should be located in a consistent area on the screen. (CforAT, 1995)

Messages, alerts, balloons, etc. should either be set to stay on the screen until dismissed, or to disappear automatically after a user-specified length of time. Warnings and other important messages should remain on screen until the user consciously acknowledges or dismisses them. (Vanderheiden, 1994)

At the top of all home pages, the first line should be a text link labeled something like, "Click here to go to text-only version of site."

Use single column text layout. (Vanderheiden, 1994)
-- Screen reading software reads only left to right; information therefore will be easier to interpret if it is presented in only one column.

Critical elements should be in the foreground. If necessary, these elements can be highlighted, or the background can be temporarily faded or eliminated. (CforAT, 1995)
-- Elements placed in the foreground are physically and cognitively easier to access.

Attach text labels to all controls and objects on the screen....Avoid use of icons without labels which are embedded in text, particularly in help files. (Vanderheiden, 1994)
-- Text labels can be read by screen readers, allowing alternative access to graphic information.

Design Web pages so that typing Page Up and Page Down scrolls in roughly half-page increments.
-- This is useful for people who cannot drag scroll bars; it will also facilitate use of the Web page with programs such as Click-It! that allow users to label and scan on-screen elements.

As a default, windows should occupy about 4/5 of the entire screen, which leaves space for on-screen keyboard use. However, the user should easily be able to enlarge the window to occupy the full screen area.

Use tags to separate different paragraphs, footnotes or other structures. The ALT Text for graphical page separators or headers can contain page information and give structural cues. (Richards)
-- This cues screen reader users as to where various structures begin and end.

The program should provide on-screen verification of user selection. (CforAT, 1995)
-- This happens visually with most links as they are clicked. At present, there is no good strategy for providing this type of verification auditorily.

Label lists with a tag at the start, such as "List with 7 choices," and then number each of the choices so that the user can remember the numbers of interest. (Richards)

If documents must be provided in a format other than HTML, provide the equivalent text file in HTML or text format. (Fontaine)

Uncommon typographic characters or constructions ("smilies," arrows consisting of dashes and greater-than signs, etc.) should be avoided. (Richards)

"Proof-read" your documents on more than one browser; lynx, Netscape, and Mosaic at the very least. You might also want to use a HTML Validation service, such as http://www.halsoft.com/html-val-svc/. (DO-IT HTML Guidelines)

Use end notes rather than footnotes. If appropriate, provide links between the reference and the end note.

Give all buttons and icons logical names, particularly in help files. (Vanderheiden, 1994)

If a caption is not a part of the button itself, use some standardized spatial relationship so that the location of a label for a button (or a button for a label) is predictable. (Vanderheiden, 1994)
-- As will be discussed elsewhere, screen readers cannot access painted (bit-mapped) text. Any button that contains only bit-mapped text, or contains no text, will need a redundant text label. (This label need not be visible; screen readers can read hidden text.)

Buttons should be at least 1" long by .5" high. This is considered large enough to allow a reasonable target area for users who cannot move the cursor with precision.

Elements that require user interaction (buttons, menus, etc.) should be located near an edge of the screen.

Make color coding redundant with other means of conveying information. (Vanderheiden, 1994)

Make sure that your program can operate in monochrome mode. (Vanderheiden, 1994)
-- This is equally important for people with monochrome monitors, for people with color blindness, and for people with low vision.

Use dark shades of blue, violet, purple or black for lettering or other important objects, and light shades of blue-green, green, yellow or orange for background. Avoid using similar hues together (e.g., don't place blue-green lettering on a blue background). (Arditi)
-- These colors provide the greatest contrast for people with low vision.

Only place text on unpatterned backgrounds. (Vanderheiden, 1994)
-- This ensures that the text can be easily read without distraction.

The user should have the option of having text read by the computer, through compatibility with screen readers. (Vanderheiden, 1994)
-- In the future, it may be possible to build text reading capability effectively and inexpensively into Web pages or browsers. For the time being, however, screen readers are the only usable strategy for both having text read and controlling important variables such as what is read, speed of reading, and assignment of different voices (different pitch, gender, etc.) used to read different types of text (e.g., links).

Provide all auditory information in a redundant visual form and vice versa....When providing a visual cue to what would otherwise be an auditory alert, it is important to ensure that the cue is sufficient to attract the user's attention when viewed out of the corner of the eye. (Vanderheiden, 1994) (See Appendix 1 for sample code illustrating strategic use of descriptive text.)

Allow the user to adjust the volume and turn non-essential sounds including background music on or off...Ensure that the program will work in noisy environments or if sound is turned off. (Vanderheiden, 1994)

Alert noises should be modifiable, especially since some noises can cause a startle reflex or other negative reactions. (CforAT, 1995)

Use appropriate sound to signal the outcome of a response-e.g., upbeat music or tones for correct answers, blues or a low-key spoken message for incorrect answers. However, make sure the auditory feedback is not a "reward" for wrong answers. (CforAT, 1995)

Avoid using any loud noises that might cause discomfort to users wearing headphones.

Support a ShowSounds feature if it exists in the operating system of your computer (a ShowSounds feature allows a user to specify that all sounds should be accompanied by a visual event including a caption for any spoken text which is not already presented on screen). (Vanderheiden, 1994)

In those cases where information is being presented via speech which is not otherwise displayed on screen, application programs might check for the "ShowSounds" switch. If the switch is set, a small box containing the text being spoken could be displayed on screen. Where music or sound is important to the operation of the program, then some description could appear in the caption box. (Vanderheiden, 1994)

(See also the section on Color and Pattern above.)

Use simple, easy-to-read typefaces with minimal or no serifs (e.g., Helvetica, Geneva, Palatino). Avoid use of italicized text or script typefaces. Avoid presenting text in all capitalized letters.

18-24 point type is recommended as a default for all essential text. (CforAT, 1995)
-- The way type is shown on the Web page is highly dependent on the browser being used and on user-definable controls within the browser. However, 18-24 point type should still be used when laying out the page, on the principle that the page is likely to keep much of its look when type is reduced, but line breaks, etc. will be affected negatively if type is enlarged.

Minimize use of "painted" (bit-mapped) text. (Vanderheiden, 1994)
-- Bit-mapped text cannot be accessed by screen readers. If use of bit-mapped text is unavoidable, make sure the content is available elsewhere as text.

Every graphic image should have associated text. (Fontaine) (See Appendix 1 for sample code illustrating strategic use of descriptive text.)

Include a description of the page layout and look in the ALT Text description or in a text version of a page of any graphics that provide organization to the document (e.g., page headers). (Richards)
-- Many people are very visually or spatially oriented despite having a visual impairment. These people want to know where images are and what they look like. (Richards)

Include detailed descriptive "comments" with all JPEG images. (Fontaine)

Place an anchor to a separate page which has a text description of the picture right next to the anchor for the picture. (Vanderheiden, 1995)

Avoid color coding, or making it redundant with pattern or some other type of coding. (Vanderheiden, 1994)

Information that is presented in charts or diagrams should also be presented redundantly in text. (Vanderheiden, 1994)

Make documentation available in electronic form (ASCII files) so that people who cannot handle or read printed manuals can access the information by screen reading software. (Vanderheiden, 1994)

Use a binding which allows a book to open and lie flat. (Try turning the pages of your documentation using the eraser end of a pencil.) (Vanderheiden, 1994)

Use a sans serif font for non-running text. (Vanderheiden, 1994)

Materials that are on either off-white or very light gray paper are generally easiest to read.

Where products are sealed for warranty or virus protection, some means for easily opening the package should be provided. (Vanderheiden, 1994)

Avoid the use of very light colors which might not be easily reproduced by copy machines, especially for important information. (Vanderheiden, 1994)
-- Also avoid using dark colors on dark backgrounds.

Fourteen-point type is recommended for maximal access.

Movies can be made accessible to hearing-impaired people through use of closed captions or other visual representations of all important information in the sound track. They can also be made accessible to visually impaired people through the use of Descriptive Video, which describes events that occur while there is no dialog. The information below describes how captions and Descriptive Video can be incorporated into programs or Web pages through use of QuickTime, etc.

"Captions:

"If the viewer being used will display 'closed' or embedded captions, captions can be embedded in the data structure for the movie.

"A strategy which works for all viewers today is to have an alternate version of the movie available with open (permanent) captions which a user can choose instead of the uncaptioned version if they wish.

"Descriptive Video:

"At the present time, the only known approach would be to have an alternate form of the movie with the descriptive narration included in the audio track." (Vanderheiden, 1995)

Make the meaningful words in a sentence into hyperlinks. In this way, someone who is skipping from link to link will get an idea of the choices available without being barraged with meaningless commands. (Richards)

If you have a list of links, provide some horizontal space between items; this makes each item easier to read.

Image Map is a strategy that allows a user to click on different parts of a picture to reference different WWW pages. (Vanderheiden, 1995) If image maps are used, there should be an alternate method of selecting options. (Fontaine)

Have an option for a text-only page which presents an alternate form of the entire page which replaces the Image Map with a text version which is optimized to work within the layout of the page. (Vanderheiden, 1995)

If possible, design the map so that the parts of the picture are large enough to be accessed easily, and are primarily arranged near an edge of the screen for maximal accessibility. You can also have an option for a text-only page that presents an alternate form of the entire page and replaces the Image Map with a text version optimized to work within the layout of the page. (Vanderheiden, 1995)

Since forms are not supported on all browsers and may be very difficult to use for people who cannot see the screen, provide the user with alternates to using a form. For example, a form for placing an order could have the redundant options of a text based form that could be downloaded and filled out with a text editor and a phone number and hours of availability for talking with a person. (Fontaine)

The following are devices that the Center for Accessible Technology (CforAT) has identified as those most commonly used to access software. It is important to contact the developers of these devices and check to make sure that nothing in your Web page design interferes with the operation of the device.

• Easy Access and CloseView (Apple, standard part of system software)
• AccessDOS (IBM, 800-426-4832)
• Access for Windows (Microsoft, 800-426-9400)
• IntelliKeys (Intellitools, 415-382-5959)
• Ke:nx (Don Johnston, 708-526-2682)
• Augmentative communication devices and TTAM (Aug. com.: Prentke Romich, 216-262-1984; TTAM: Trace R&D Center, 608-262-6966)
• HeadMaster (Prentke Romich, 216-262-1984)
• Screen Enlargement Software (Mac: Berkeley Access, 510-540-5535; Windows: Syntha-Voice, 800-263-4540; Optelec, 800-828-1056)
• Screen Reading Software (Mac/Windows: Berkeley Access, 510-540-5535; Windows: Henter-Joyce, 813-528-8900; Artic Technologies, 313-588-7370)
• WiViK 2 Scan (Hugh Macmillan Rehab Centre, 416-425-6220)
• Word Prediction Software (Words + Inc., 805-869-8521; Pointer Systems Inc.,
• 802-658-3260; Madenta, 403-450-8926)
• One Single and One Dual Switch (Zygo, 503-684-6006; Tash Inc., 416-686-4129;
• AbleNet, 612-379-0956; DU-IT, 216-567-2906)

Access Technology

Any of a variety of software and/or hardware products that compensate for an individual's inability to use standard computer screens, keyboards, or mice. Examples include screen readers, alternative mice (such as joysticks), scanning technology, and membrane keyboards.

Hyperlinks

See Links.

Links

A standard Web page component; clicking on a link will automatically take you to another Web page in the same site, another section of the current Web page, or another Web site. Links usually appear in the form of highlighted text or buttons. Also known as "hyperlinks."

Scanning

Many individuals who cannot use a standard keyboard for input use scanning technology. This usually consists of software that lets the user jump among on-screen elements; depending on the software, this may (etc.)

Screen Reader

A software program that enables users with visual or learning disabilities to have on-screen textual information read to them. The Macintosh and Windows screen readers also include mouse emulation, so that users can issue standard or special (e.g., "Jump to Menu Bar") commands from the keypad. May also be called "screen-review program."

People with visual disabilities cannot access graphic elements; people with hearing disabilities cannot access sounds. Both problems can be solved by strategic use of descriptive text. The blind or deaf user clicks on a recognizable hyperlink symbol (say a "D" for text describing a graphic and "CC" for transliteration or explanation of audio information) and gains alternative access to graphic or auditory information. (The WGBH Web page at www.wgbh.com is an excellent example of how descriptive text can be used to enhance accessibility.)

Below is an example based on the White House Web server, courtesy of Paul Fontaine at the General Services Administration....This example includes both ALT-TEXT access to the sound icon (audio.gif) (for users who are using text browsers or screen readers) and the text translation (al npr intro.html) of the audio file (gore.au) (for users who cannot hear or do not have audio capabilities on their computers.)

Suggested code:

The President asked <A HREF="http://www.ostp.eop.gov/images/raw/al-portrait.gif><IMG SRC="http://www.ostp.eop.gov/images/small/al-portrait.gif" ALT="Picture of Al Gore">Vice President Gore</A>to head up the <A HREF="http://www.npr.gov/">National PerformanceReview (NPR)</A), a project to make government workbetter and cost less. You can <A HREF="http://www.ostp.eop.gov/sounds/gore.au"><IMG SRC="http://www.ostp.eop.gov/icons/audio.gif" ALT="Sound Icon"> hear </A> or <A HREF="http://www.npr.gov/al npr intro.html">read</A> Mr. Gore"s speech introducing NPR." (Vanderheiden, 1995)

Additional code for describing graphics:

"Incorporate both the graphic AND TEXT within the anchor. The ALT-TEXT text should also be included for those browsers that support it. However, since the graphic browsers do not currently support it, it should not be relied on. The format should therefore be:

"Running text on the page <A HREF="http://www.your.host/path/filename.html"> <IMG SRC="http://www.your.host.path/filename.gif" ALT="Text describing picture.">running text that could serve as anchor instead of or in addition to the in-line picture</A>rest of running text....

"An example:

The newest product in our line is the <A HREF="http://www.xyz.com/products/magicom.html"<IMG SRC="http://www.xyz.com/products/images/magicom.gif" ALT="Picture of Magicom Phones">Magicom portable phone</A>, the world's smallest portable phone.

which yields:

The newest product in our line is the Picture of Magicom Phones Magicom portable phone, the world's smallest portable pocket phone.

OR

The newest product in our line is the <A HREF="http://www.xyz.com/products/magicom.html"Magicom portable phone<IMG SRC="http://www.xyz.com/products/images/magicom.gif" ALT="Picture of Magicom Phones"></A>, the world's smallest portable pocket phone.

which yields:

The newest product in our line is the Magicom portable phone, Picture of Magicom Phones the world's smallest portable pocket phone.

"Another higher-tech approach is to create a database-based server that creates HTML pages on demand when the user asks for them. In this manner, the pages can be constructed with or without graphics as desired by the user. An example of this is the CommerceNet server." (Vanderheiden, 1995)

NOTE: As of this draft, these settings are primarily relevant to MS-Windows (presumably 3.1; possibly 95). Similar guidelines are forthcoming for Macintosh and will be incorporated here as soon as they are published.

"Tool bars" - On: the tool bar is often more convenient for user with limited use of mouse or trackball.

"Window placement" - Set for short and wide for on screen keyboard placement. otherwise, set for full screen for maximum view.

"Viewers" - Choose viewer with best access features

"Services" - Setting up news reader and Email features can simplify interactions by making these tasks available within Mosaic.

"Anchors" - Highlighting gives contrast and makes possible selecting an anchor with arrow keys." ("Mosaic 2.0 0b1 MS Windows Version")

"Inline images" - OFF:....if off an ALT TAG (author created text description of image) is displayed and is readable by the screen reader....

"Misc" - 3D rules ON may be more visible.

"Background color" - Color and contrast can help low vision users.

Presentation mode can also be used to set window to full screen.

Font magnification can be achieved by using the '+' and '-' keys." ("Mosaic 2.0 0b1 MS Windows Version")

NOTE: Some screen readers permit the user to search for underlined text, or provide notification when the cursor shape changes. Both of these are useful in finding links.

1. Panorama (by SoftQuad)

"The goal of this project is to develop and begin commercialization of a software browsing tool for networked environments including the Internet and the World Wide Web. Unlike presently available World Wide Web browsers, this browser will be accessible to people with disabilities who require alternative computer access systems. The browser will also exploit previous SoftQuad development by incorporating full SGML viewing capabilities. SGML is recognized as a mark-up standard in the academic, aerospace, automotive, computer, semi-conductor and publishing fields. The product will be released on three platforms, namely: Macintosh, Microsoft Windows and UNIX....

"The proposed browser will be made accessible in four ways:

1. It will be optimally compatible with alternative access systems a disabled individual may wish to use.
2. It will provide a large number of integrated alternative access features, such as scanning, screen magnification and screen reading.
3. It will allow the user to setup individual profiles to specify desired display features (e.g., in Braille ready format) or input features (e.g., MouseKeys rather than mouse control).
4. It will incorporate recommendations made by browser usability studies (e.g., more easy to use navigation tools, improved search utilities, a more consistent interface) (Beabes, Webber, 1995). Thus the browser will be better configured for all users, with or without disabilities." ("Panorama")

NOTE: A conversation with Donald Teed of SoftQuad revealed that Panorama is intended for use as a supplement to existing browsers, not as a stand-alone browser.

2. DVL/NCSA Project

"The Design Visualization Laboratory (DVL) is an instructional/ research facility in the School of Art and Design at the University of Illinois at Chicago (UIC)....The DVL is working with the National Center for Supercomputing Applications (NCSA) to develop a plan to make current and future versions of NCSA Mosaic accessible to people with disabilities. The project is also looking into accessible user interfaces to the Internet and World Wide Web in general. A WEB server has been set up to provide information for people concerned with access to the "Information Superhighway." ("Welcome to the Design Visualization Library")

"Here's a summary of the recent changes to Mosaic to facilitate operation by people with various disabilities:

1. Implemented on the Mac and Windows platforms the display of ALT (text) tags on IMGs whenever auto-load of images is turned off. (Also benefits the 'bandwidth impaired.')
2. Provided the ability to control font selection and size for all HTML text types on both the Mac and Windows platforms.
3. Provided the ability to control background color from the entire spectrum and intensity range for both the Mac and Windows platform.
4. Provided the ability to control font colors for all HTML text types on both the Mac (whole-spectrum, all intensities) and Windows (16 color choices).
5. Provided the ability to completely change the default rendering instructions for both the Mac (by launching Mosaic via double-clicking on any set of reference files you've built for yourself) and Windows (by commanding the use of a different file to fulfill the role of "Mosaic.ini") platforms....The user...will not have to item-by-item reconfigure the Browser each time it is to be used.
6. Implemented on the Windows platform the use of left and right arrow keys as a means of navigation to the next adjacent hyperlink. Further, the user has the choice of 3 ways to indicate which anchor is 'current' (i.e., will be fetched if RETURN is pressed), and one of these choices is a bordering box of any selectable color/intensity.
7. Added command icons to the Windows platform which are taken from the 'standard' Microsoft collection, hopefully facilitating interoperability with Screen readers.
8. Added a series of auto-triggering events in Windows Mosaic. Upon one of these events occurring, Mosaic can now trigger a user-chosen, user-supplied audio file. Different audio files can be chosen for each supported event.
9. Continued to extend our bi-directional interface between Mosaic and sibling processes, to facilitate all forms of interactive augmentation, including (potentially) HTML-aware screen reader software. (We have provided the copyrighted Mosaic source code to at least 2 universities recently who are working on such screen readers.)" ("Recent Changes to Mosaic Improving Access")

Note: Some web sites are introducing special data structures and viewers to differentiate themselves or provide special functions not available with the standard tools. The only way for these custom data and views to be accessible is if the access is built directly into the viewer. Standard access tools do not generally work with special viewers. (Vanderheiden, 1995)

BIBLIOGRAPHY

Arditi, Ardis, Ph.D. "Color Contrast and Partial Sight." Lighthouse for the Blind, year? 8 p. pamphlet

Center for Accessible Technology (CforAT). "Accessible Software for 4th-7th Grade Students with Physical Disabilities." 1995.

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

Fontaine, Paul. "Writing Accessible HTML Documents." World Wide Web page http://www.gsa.gov/coca/WWWcode.htm

"Mosaic 2.0 0b1 MS Windows Version." World Wide Web page http://bucky.aa.uic.edu/HTML/MS_Access.html

"Panorama." World Wide Web page http://www.utirc.utoronto.ca/AdTech/rd/panorama/panoramasr.html

"Recent Changes to Mosaic Improving Access." World Wide Web page http://bucky.aa.uic.edu/HTML/moschngs.html

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

Vanderheiden, Gregg, editor. "Application Software Design Guidelines: Increasing the Accessibility of Application Software to People with Disabilities and Older Users." Version 1.1, June 15, 1994 Revision. 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/

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/

"Welcome to the Design Visualization Library." World Wide Web page http://bucky.aa.uic.edu/