Executive Summary

There are many people who need to be able to use standard software programs in their jobs, schools or homes but are unable to because of the design of the programs or their interfaces. These people, because of accident, illness, congenital condition or aging have reduced visual, hearing, physical or cognitive/language abilities. The current estimate of people with disabilities is over 40 million people -- a sizable portion of our population.

Shared responsibility

Making computers and software accessible to people with disabilities is not just the responsibility of application software developers. In fact there is only so much of the problem that can be address ate the application software level. System software manufacturers and 3rd party disability access software and hardware developers also need to play an important role.

Purpose of the guidelines

The purpose of these guidelines is to document what application developers can do (or need to do) in order to make their software accessible and usable by people who have disabilities or reduced abilities due to aging.

The guidelines document does this by providing information on the problems faced by people with disabilities in using current software and documenting ways in which application software can be made more accessible and usable by them. The document also describes the roles of the other players (system software developers, 3rd party developers etc.) in this process along with the types of access modifications available from them.

As you read the guidelines, you will also see that the recommendations can increase the usability of the software to people without disabilities as well. In some cases the recommendations make the programs easier to use. In other cases they increase the ability of the software to work with other software, with scripting utilities, or with alternate input (e.g., voice input) or output (e.g., speech output) technologies.

3 Basic Components

Basically, making application software more accessible consists of three complementary components:

1. Designing your software so that it is as usable as possible to the greatest number of people - without requiring them to use special adaptive software or hardware. (This is referred to as Direct Accessibility).

2. Designing your software in such a way that it will work with special access features built into the operating system or attached to it by users who require them.
(i.e., Compatibility with operating system or third-party access features / software / devices for those people who will not be able to use your software directly.)

3. Making sure that your documentation, training, and customer support systems are accessible.

A brief sumnmary of the guidelines by disability area follows.

For people with physical disabilities

People with physical disabilities can have a wide range of abilities and limitations. Some people may have complete paralysis below the waist but may have no disability at all with their upper body. Others may have weakness overall. Some may have very limited range of motion, but may have very fine movement control within that range. Others may have little control of any of their limbs, or may have uncontrolled, sporadic movements which accompany their purposeful movements. Some with arthritis may find that hand and other joint movement is both physically limited and limited by pain.

A physical disability, by itself, does not usually affect a person's ability to perceive information displayed on the computer screen. Access is generally dependent on being able to manipulate the interface.

Therefore, you can increase the accessibility of your software (both direct and via access features/software and hardware)

• by avoiding timed responses (less than 5-8 sec.) or allowing the response time to be changed;
• by providing keyboard access to all toolbars, menus, and dialog boxes (whose functions are not also in the menu);
• by not interfering with access features built into the operating system (e.g. StickyKeys, SlowKeys, Key Repeating etc.)

For people who are hard of hearing or deaf

Many users with hearing impairments need to have some method for adjusting the volume or for coupling the sounds more directly to their hearing aids. Both of these are hardware considerations and can be met with systems having volume controls and headphone or audio jacks. Users who have more severe hearing impairments may also use a combination of these techniques, as well as techniques for people who are deaf. Such techniques generally involve the visual display of auditory information.

Therefore, you can increase the accessibility of your software to users with hearing impairments

• by providing all auditory information in a visual form as well;
• by ensuring that all visual cues are noticeable if one is not looking at the screen;
• by having a mode of operation that will work in noisy environments or if sound is turned off;
• by supporting a ShowSounds feature if it exists in the operating system of your computer (a ShowSounds feature allows a user to specify that all sound should be accompanied by a visual event including a caption for any spoken text which is not already presented on screen.).

In addition, you should make sure that product support people are reachable via Text Telephones (also called TDD's or Telecommunications Devices for the Deaf).

For people with color blindness

You can increase the compatibility of your software with access features/software

• by making color coding redundant with other means of conveying information;
• by making sure that your program can operate in monochrome mode;
• by using colors which differ in darkness so that they can be distinguished by this as well as color.

For people with low vision

People with low vision may have any one of a number of problems with their vision ranging from poor acuity (blurred or fogged vision) to loss of all central vision (only see with edges of their eyes) to tunnel vision (like looking through a tube or soda straw) to loss of vision in different parts of their visual field, as well as other problems (glare, night blindness, etc.).

For people with low vision, a common way to access the information on the screen is to enlarge or otherwise enhance the current area of focus. Given this, you can increase the direct accessibility of your software

• by allowing the user to adjust the fonts, colors and cursors used in your program to make them more visible;
• by using a high contrast between text and background;
• by not placing text over a patterned background where the two might interfere with each other;
• by using a consistent or predictable layout for screens and dialogs within the program
• by providing access to tools, etc., via menu bar;
• by using recommended line width information when drawing lines (if such information is provided by the system).

In addition, you can increase the compatibility of your software with low vision access features/software

• by using the system pointers wherever possible, as well as the system caret or insertion bar if one is available.
• If you use your own highlight/focus indicator, drag the system cursor with you ½ even if it is invisible. This makes tracking the focus much easier for screen enlargement or "pan and zoom" features.
• If the operating system has a High Contrast setting, support it.

For people who are blind

Many people who are legally blind have some residual vision. This may vary from just an ability to perceive light to an ability to view things that are magnified. The best design is for this group is therefore one that doesn't assume any vision but allows a person to make use of whatever residual vision they may have.

Access by people who are blind is usually accomplished using special screen reading software to access and read the contents of the screen, which is then sent to a voice synthesizer or dynamic braille display.

On computers which use a graphic user interface this is a bit tricky, but there are a number of things that application software developers can do to make it possible for people using screen readers to detect and figure out what is on the screen. These include

• using the system tools wherever you can to;
  1. draw and erase all text on the screen;
  2. display all cursors and pointers;
• using the system standard controls whenever possible;
• drawing tools in tool bars, palettes and menus that are separate items (rather than one big graphic of toolbar) as this makes it possible for screen readers to identify the number, location and shape of the individual tools so that they can be identified and named.

You can also increase the compatibility of your software with screen readers using the following considerations:

• if text is embedded in a graphic image, using a special technique to make the text known to screen reading software (see detailed notes);
• if you use your own highlight or focus techniques, dragging system cursors with you (even if invisible);
• using consistent or predictable screen and dialog layouts;
• not using pop-up help balloons that disappear if the focus changes unless there is a way to lock them in place so that the focus (e.g., cursor) can be moved there to read them;
• using single column text whenever possible;
• giving controls logical names, even if the name is not visible on screen (screen readers can access this information and use it to describe the type and function of the control on the screen).
• providing keyboard access to all tools, menus, and dialog boxes.

Since screen readers can only read text (or give names to separately identifiable icons or tools) it is a good idea to:

• avoid unlabeled "hot spots" on pictures as a control scheme (unless redundant with menu selection);
• avoid non-text menu items when possible or incorporate cues (visible or invisible) (screen readers can 'see' text that is written to screen in an invisible color);
• avoid non-redundant graphic tool bars if possible.

Finally, you can make your documentation and training materials more accessible

• by designing all documentation and on line help so that it can be understood by reading the text only (e.g. information presented in pictures and graphics is also presented with a description in text);
• by providing synchronized running audio descriptions for all information presented as an animated graphic or movie.

For people with language or cognitive disabilities

This is perhaps one of the most difficult areas to address. Part of the difficulty lies in the tremendous diversity that this category represents. It includes individuals with general processing difficulties (mental retardation, brain injury, etc.), people with very specific types of deficits (short term memory, inability to remember proper names, etc.), learning disabilities, language delays, and more. In addition, the range of impairment within each of the categories can (like all disabilities) vary from minimal to severe, with all points in between. In general, software that is designed to be very user friendly can facilitate access to people with language or cognitive impairments.

Somewhat more specifically, you can increase the accessibility of your software

• by making sure that all messages and alerts stay on screen until they are dismissed;
• by making language as simple and straightforward as possible, both on screen and in the documentation;
• by using simple and consistent screen layouts.

In addition, because print disabilities are more common among people with language and cognitive impairments, you can increase the accessibility of your software by ensuring that it is compatible with screen reading software. (See the section titled "For People Who Are Blind," above.)

For people in general

Finally, you can increase the overall accessibility of your software

• by making sure that your documentation is available in electronic form (that can be accessed by screen reading software) so that it is available to people who cannot handle or read your printed manuals;
• by making sure that your product support people are aware of disability access issues and are aware that people with disabilities routinely use your products;
• by having particular product support people identified who specialize in handling any incompatibility associated with the use of your product with disability access products (all support people should be able to handle regular product use questions of people who have disabilities, but it is usually helpful to focus incompatibility problems to a few people who can become more familiar with the issues and work arounds);
• by forwarding any access or compatibility problems identified by product support people to product designers (and setting lower trigger levels for incidence vs. priority for fixing).