Removing barriers to access often results in benefits for a wide range of people--not only those with disabilities. For example, until curb cut ramps were placed on sidewalks, it was difficult or impossible for people in wheelchairs to cross a street. In addition to providing a wheelchair solution, curb cuts have benefited people on bicycles, as well as those pushing shopping carts and baby carriages.
Designing accessible software has similar beneficial consequences for a wide range of users. Solutions that allow use of the keyboard instead of the mouse aid users involved in keyboard-intensive tasks. Users of portables or those in open offices with telephones ringing may not be able to use or hear sounds. Providing visual cues to augment or replace audible cues assists these users, in addition to assisting hearing impaired users.
There is a growing market for accessible computer products. Approximately 40 million Americans have a disability of some type, and as the population ages, more and more people will develop age-related disabilities (25% by age 55, jumping to 50% at age 65).
Like all computer users, users with disabilities vary in age, computer experience, interests, and education. When barriers are removed, the computer gives them a tool to compete with all other users on an equal basis. Users with disabilities are engineers, artists, scientists, designers, lawyers, administrative assistants, and software engineers. The common thread among these diverse users is that computers play an important role in their daily work.
Not only does providing access provide benefits for a wide range of users, but it is also a requirement in all current federal contracts under section 508 of the Federal Rehabilitation Act. In the commercial sector, the Americans with Disabilities Act (ADA) calls for similar considerations when reasonably accommodating current and prospective employees.
The easiest way to ensure accessible applications is to follow the style guidelines, and to read and follow the advice offered in this chapter.
While physical capabilities vary greatly between and within the disability examples cited, they have a common requirement for keyboard access to all controls, features, and information in application software. Providing comprehensive keyboard access is essential to ensure that the user who cannot utilize a mouse can productively use Motif applications.
Full keyboard access to an application is necessary, but not sufficient to make applications accessible. The other central requirement is to follow the key mapping guidelines found throughout this style guide. Consistent use of these mappings not only provides more usable applications for all users by reducing learning across applications, but also increases the effectiveness of alternate I/O technology such as speech control and screen reading software.
Recommended
id:
Reading small fonts can be challenging for users with low vision. All fonts, including those in text panes, menus, labels, and information messages should be easily configurable by the user--font size and type should never be hard coded.
Interpreting information that depends upon color (for example, red = stop, green = go) can be difficult for people with visual impairments. A significant number of people are color blind and are unable to see differences between some colors. For these reasons, never use color as the only source of information.
In addition to being difficult to interpret, some background and text color combinations can result in text that is difficult to read for users with visual impairments. Again, the key is to provide choice. Never hard code color choices. Users should always have the capability to override default colors, so they can choose the colors that work best for them.
Provide meaningful names for every widget instance. Meaningful names help screen reading software give useful information to users with visual impairments. Rather than naming an eraser graphic widget5, for example, call it eraser or some other such descriptive name.
Without such descriptive information, blind or low-vision users cannot interpret unlabeled, graphically labeled, or custom widgets. Providing this information is a requirement for access in such cases. As an added bonus, meaningful widget names make for code that is easier to debug.
Finally, remember that many users with visual disabilities depend upon keyboard navigation and control, and they will not be using a pointing device.
Recommended
ie:
Recommended
if:
Recommended
ig:
Recommended
ih:
Never assume that users will hear an auditory notice. Remember that users sitting in airplanes, in noisy offices, or in other public places where sound must be turned off need the same types of visual notification as hearing impaired users. Additionally, some users are able to hear audible cues only at certain frequencies or volumes. Volume and frequency of audio feedback should be easily configurable by the user. Never hard code these parameters.
Sounds unaccompanied by visual notification, such as a beep indicating that a print job is complete, are of no value to users with hearing impairments or others who are not using sound. While such sounds can be valuable, never create a design that assumes sounds will be heard.
On the other hand, it would be intrusive for most users to see a warning window whenever a printout is ready. Visual notices can take the form of changing an icon, posting a message in an information area, or providing a message window as appropriate. Anyone using a system in a public area will benefit from the option of choosing to see rather than hear such notices.
The key point is to provide users with a choice. When appropriate, provide visual as well as audio notification. If visual notification does not make sense as the default behavior, then be sure to provide it as an option.
Recommended
ii:
Recommended
ij:
Recommended
ik:
Recommended
il:
Recommended
im:
The built-in, server-level access features include:
Recommended
in:
Clearinghouse on Computer Accommodation (COCA) 18th & F Streets, NW Room 1213 Washington, DC 20405 (202) 501-4906A central clearinghouse of information on technology and accessibility. COCA documentation covers products, government resources, user requirements, legal requirements, and much more.
Sensory Access Foundation 385 Sherman Avenue, Suite 2 Palo Alto, CA 94306 (415) 329-0430A nonprofit organization that consults on application of technology "to increase options for visually and hearing impaired persons." Publishes newsletters on adaptive technology.
Special Needs Project 3463 State Street Santa Barbara, CA 93105 (805) 683-9633Vendor of books for professionals and families on a wide variety of disability issues.
Trace Research and Development Center S-151 Waisman Center 1500 Highland Avenue Madison, WI 53528 (608) 262-6966A central source for the current information on assistive technologies as well as a major research and evaluation center. Trace distributes databases and papers on adaptive technology and resources.
CSUN Conference on Technology and Persons with Disabilities Every spring in Los Angeles, California (818) 885-2578Closing the Gap Conference on Microcomputer Technology in Special Education and Rehabilitation Every fall in Minneapolis, Minnesota (612) 248-3294
Cornsweet, T.N. Visual Perception. Academic Press, New York. 1970.
Edwards, A., Edwards, E., and Mynatt, E. Enabling Technology for Users with Special Needs (InterCHI '93 Tutorial). 1993.
Johnson, M, and Elkins, S. Reporting on Disability. Advocado Press, Lousville, KY, 1989.
Managing Information Resources for Accessibility, U.S. General Services Administration Information Resources Management Service, Clearinghouse on Computer Accommodation, 1991.
Vanderheiden, G.C., Thirty-Something Million: Should They Be Exceptions?, Human Factors, 32(4), 383-396. 1990
Vanderheiden, G.C. Making Software More Accessible for People with Disabilities, Release 1.2. Trace Research & Development Center, 1992.
Walker, W.D., Novak, M.E., Tumblin, H.R., Vanderheiden, G.C. Making the X Window System Accessible to People with Disabilities. Proceedings: 7th Annual X Technical Conference. O'Reilly & Associates, 1993.