Accessibility: Design of Accessible Web Pages (1996)
Design of Accessible Web Pages
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
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
1. Layout Design
3. Special Topics
4. Specific Adaptive Technologies
Appendix 1: Setting Preferences Within an Operating System
Appendix 2: Coding For Alternate Access
Appendix 3: Accessible Browser Initiatives
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.
1. Layout Design
a. General Design
Keep layouts simple and straightforward. (Vanderheiden, 1995)
Make language as simple and straightforward as possible on screen. (Vanderheiden,
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)
Critical elements should be in the foreground. If necessary, these elements
can be highlighted, or the background can be temporarily faded or eliminated.
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)
Design Web pages so that typing Page Up and Page Down scrolls in roughly
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)
The program should provide on-screen verification of user selection. (CforAT, 1995)
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.
b. Buttons and Icons
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)
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.
c. Color and Pattern
Make color coding redundant with other means of conveying information. (Vanderheiden, 1994)
Make sure that your program can operate in monochrome mode. (Vanderheiden,
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)
Only place text on unpatterned backgrounds. (Vanderheiden, 1994)
d. Speech and Sound
The user should have the option of having text read by the computer, through
compatibility with screen readers. (Vanderheiden, 1994)
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,
Minimize use of "painted" (bit-mapped) text. (Vanderheiden, 1994)
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)
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)
Fourteen-point type is recommended for maximal access.
3. Special Topics
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.
"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.
"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.
c. Image Maps
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)
4. Specific Adaptive Technologies
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.
Appendix 1: Coding For Alternate Access
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.)
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:
The newest product in our line is the Picture of Magicom Phones Magicom portable phone, the world's smallest portable pocket phone.
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)
Appendix 2. Setting Preferences Within an Operating System
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.
Appendix 3: Accessible Browser Initiatives
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:
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:
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)
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.
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/