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 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:
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.
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.
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 "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:
Allow users to configure all of the fonts in your application, including text in text-entry fields, menus, labels, and messages.
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.
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.
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.
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" 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:
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.
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.
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".
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:
The guidelines outlined for physical, visual, and hearing disabilities also typically benefit users with cognitive, language, and other disabilities.