Accessibility means enabling people with disabilities to participate in substantial life activities, including the use of services, products, and information.
Removing barriers to access often results in benefits for many people — not only those with disabilities. For example, curb-cut ramps benefit wheelchair users as well as people on bicycles and those pushing shopping carts or baby carriages.
Designing accessible software has similar benefits for a wide range of users. Solutions that use the keyboard instead of the mouse aid in keyboard-intensive tasks. Visual cues help hearing-impaired users as well as those in noisy offices or using portable computers in public places.
U.S. Government statistics show that 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 of the population will develop age-related disabilities (25% by age 55; 50% by age 65).
Not only is providing access the right thing to do, section 508 of the Federal Rehabilitation Act calls for it to be required in federal contracts. In the commercial sector, the Americans with Disabilities Act (ADA) calls for similar considerations.
Designing for accessibility also helps your customers meet their current and emerging requirements for accessible products.
Many users with disabilities can use applications without any adjunct assistive software or hardware; others may use additional technology such as screen readers or speech-recognition software. The guidelines in this chapter specify standardized methods of interaction that allow users with disabilities to access applications either directly or through assistive software and hardware.
Like any computer user, users with disabilities vary in age, computer experience, interests, and education. When barriers are removed, the computer gives them a tool to compete with users without disabilities on an equal basis. Users with disabilities may be engineers, artists, scientists, designers, lawyers, administrative assistants, and software engineers. The common thread among the people in these diverse professions is that computers play an important role in their daily work.
The following sections discuss how to write interfaces for users who have the following disabilities:
Physical
Visual
Hearing
Language, cognitive, and other
Physical disabilities can be the result of congenital conditions, accidents, or excessive muscular strain. Examples include spinal cord injuries, degenerative nerve diseases, stroke, and typing-based repetitive stress.
The following design principles address creating applications for those users with physical disabilities:
Use new technology to aid in developing your application
Adaptive hardware and software capable of optical character recognition, word prediction, eye scanning, and synthesized speech can give users with physical disabilities alternatives to keyboard and mouse interaction.
Provide keyboard access to all application features.
While physical capabilities vary greatly, users all need keyboard access to the controls, features, and information in applications. Providing comprehensive keyboard access is essential to ensure that the user who cannot use a mouse can productively use your application.
Follow the key-mapping guidelines in this chapter and throughout the style guide.
Consistent use of these mappings provides applications that are easier to use and increases the effectiveness of alternate input/output technology, such as speech control and screen readers for blind individuals.
For more information, see Chapter 6, “Selection”, Appendix B, “Keyboard Model and Key Bindings”, and the Keyboard (Device) reference page.
Effects of visual disabilities range from reduced visual acuity, requiring reading glasses, to people who need large-size displays, to the completely blind who require screen-reading software that allows them to navigate and to hear what is on the screen. As with physical disabilities, it is crucial that your application provide complete keyboard access.
The following design principles address creating applications for those users with visual disabilities:
Do not hard code font sizes and type faces.
Allow users to configure all of the fonts in your application, including text in text-entry fields, menus, labels, and messages.
Do not hard code your application colors.
In addition to being difficult to interpret, some background and text color combinations can result in text that is difficult to read. Users should always have the capability to override default colors so that they can choose the colors that work best for them.
Never use color as the only source of information.
Interpreting information that depends upon color (for example, red=stop, green=go) is particularly difficult for those who are color blind or unable to see differences among some colors.
Do not hard code graphic attributes such as line, border, and shadow thickness.
Allow users to change the attributes of window controls for sizing and separation. A window border, shadow, or separator that is too thin or thick can be difficult to identify or may distort the user's focus.
Provide meaningful names for controls.
If you use nonstandard (for example, custom) controls, or standard controls without text (for example, push buttons or a palette with graphics), then you must give each control a meaningful name. Rather than calling an eraser graphic “control5,” for example, call it “eraser.” Users who rely on screen reading and character recognition devices will not understand the control's purpose unless it has a meaningful name.
For more information, see “Visual Cues” in Chapter 4 and the Control, Label, and Text-Entry Field (Control) reference pages.
People with hearing disabilities cannot hear sound output at typical volumes, if at all. In some cases, users can hear audible cues only at certain frequencies or volumes.
The following design principles address creating applications for those with hearing disabilities:
Do not overuse or rely exclusively on audible cues.
Never assume that a user can hear an auditory notice. Even users who are not hearing impaired are often unable to use sound because they are in a noisy office or using a portable computer in an area where sound is prohibited.
Sounds unaccompanied by visual notification, such as a beep indicating that a print job has completed, are of no value to hearing-impaired users or others who are not using sound. While such sounds can be valuable, never create a design that works on the assumption that they will be heard.
Where appropriate, allow users to choose between audible or visual cues.
There are times when either an audible cue or a visual cue is more appropriate. For example, hearing-impaired users and anybody using a system in a public area would benefit from the option of choosing to see rather than to hear a notice. Such notices can take the form of a changing icon or a message in an information area window.
On the other hand, in the printer example it would be intrusive for most users to see a warning window every time a printout is ready. Therefore an audible cue is more appropriate.
Allow users to configure the frequency and volume of audible cues.
Every user has different hearing abilities. Allowing the user to change the frequency and volume of an audible cue helps to ensure that the user will both hear the cue and distinguish it from other audible cues.
For more information, see “Audible Cues” in Chapter 4.
The wide range of disabilities is too broad to cover extensively. However, users with language, cognitive, and other disabilities can benefit from an application that:
Allows flexible limits for task completion
Minimizes the use of transitory signals
Reduces the user's memory requirements
The guidelines outlined for physical, visual, and hearing disabilities also typically benefit users with cognitive, language, and other disabilities.
When designing Motif applications, be aware of existing system-level keymappings that access features used in the X Windows server. These server features, known as AccessX, provide basic workstation accessibility, typically used by people with mobility impairments. AccessX became a supported part of the X Windows server in Version X11/R6.
The built-in server-level access features include:
| StickyKeys | Provides locking or latching of modifier keys (for example, Shift, Control) so that they can be used without simultaneously pressing the keys being modified. This allows single-finger operation of multiple key combinations. | |
| RepeatKeys | Delays the onset of key repeat, allowing a user with limited coordination time to release keys before multiple characters are sent. | |
| SlowKeys | Requires a key to be held down for a set period before keypress acceptance. This allows a user with limited coordination to accidentally press keys without sending too many keypress events. | |
| MouseKeys | An alternative to using the mouse, provides keyboard-based explicit control of cursor movement and all mouse button press/release events. | |
| ToggleKeys | Indicates a locking key state with a tone when pressed, for example, Caps Lock. | |
| BounceKeys | Requires a delay between keystrokes before accepting the next keypress so a user with tremors can accidentally press the same key without sending too many keypress events. |
To avoid conflicts between Motif applications and current and future access tools, use Table 12-1, which lists the key mappings that have been reserved for AccessX.
Table 12-1. AccessX Key Mappings
| Keyboard Mapping | Reserved For |
|---|---|
| 5 consecutive clicks of shift | On/Off for StickyKeys |
| Shift held down 8 seconds | On/Off for SlowKeys and RepeatKeys |
| 6 consecutive clicks of Ctrl | On/Off for screen-reader numeric keypad functions. |
| 6 consecutive clicks of Alt | Reserved for future AccessX use. |
For more information about software accessibility, consult the following organizations, conferences, and books:
Clearinghouse on Computer Accommodation (COCA)
18th & F Streets, NW
Room 1213
Washington, DC 20405
(202) 501-4906
A 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-0430
A 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-9633
Vendor of books on a wide variety of disability issues for professionals and families.
Trace Research and Development Center
S-151 Waisman Center
1500 Highland Avenue
Madison, WI 53528
(608) 262-6966
A 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.