Common Desktop Environment: Style Guide and Certification Checklist

# 9 Designing for Accessibility

Contents of Chapter:

Accessibility

Access and the Style Guide

Physical Disabilities
  Guideline

Visual Disabilities
  Guidelines

Hearing Disabilities
  Guidelines

Language, Cognitive, and Other Disabilities
  Guidelines

Existing Keyboard Access Features
  Guideline

Resources for More Information on Accessibility
  Organizations
  Conferences
  Bibliography

This chapter provides guidelines for making software applications accessible to people with disabilities.

## Accessibility

Accessibility means removing barriers that can prevent people with disabilities from participating in substantial life activities, including the use of services, products, and information.

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.

## Access and the Style Guide

Many users with disabilities can use application software without any adjunct adaptive software or hardware, while others may use additional technology such as screen readers or speech recognition. In either case, it is important to follow required style guidelines because those guidelines provide standard methods that make it possible for users with disabilities to access applications either directly or through adaptive software and hardware.

The easiest way to ensure accessible applications is to follow the style guidelines, and to read and follow the advice offered in this chapter.

## Physical 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 repetitive stress injuries.

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.

### Guideline

    Recommended

id:

  All application functions are accessible from the keyboard. See link.

## Visual Disabilities

Visual disabilities may require use of tools ranging from reading glasses, to large-sized displays and fonts, to screen reading software that enables completely blind users to navigate and hear what is on the screen.

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.

### Guidelines

    Recommended

ie:

  Colors should not be hard coded. See link.

    Recommended

if:

  Graphic attributes, such as line, border, and shadow, should not be hard coded. See link.

    Recommended

ig:

  Font sizes and styles should not be hard coded. See link.

    Recommended

ih:

  All application code uses descriptive names for widgets. Such descriptive names for widgets using graphics instead of text (for example, palette items and icons) allow screen reading software to provide descriptive information to blind users. See link .

## Hearing Disabilities

People with hearing disabilities either cannot detect sound or may have difficulty distinguishing audio output from typical background noise.

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.

### Guidelines

    Recommended

ii:

  Interactions do not depend upon the assumption that a user will hear an audible notification. See link.

    Recommended

ij:

  Where appropriate, users can choose to receive cues as audio or visual information. See link.

    Recommended

ik:

  The application does not overuse or rely exclusively on audible information. See link.

    Recommended

il:

  Users can choose to configure the frequency and volume of audible cues. See link.

## Language, Cognitive, and Other Disabilities

The access guidelines outlined for visual, hearing, and physical disabilities typically benefit users with cognitive, language, and other disabilities by allowing them to choose effective means of communication, sometimes through the use of adaptive technology.

### Guidelines

    Recommended

im:

  Tear-off menus and user configurable menus for key application features may be provided for users with language and cognitive disabilities. See link.

## Existing Keyboard Access Features

When designing CDE Motif applications, be aware of existing system-level key mappings used by access features in the X Window SystemTM 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 X11R6.

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. StickyKeys allow single-finger operation of multiple key combinations.

RepeatKeys
  Delays the onset of key repeat, allowing users with limited coordination time to release keys before multiple characters are sent.

SlowKeys
  Requires a key to be pressed and held for a set period before keypress acceptance. This allows users with limited coordination to accidentally press keys without sending keypress events.

MouseKeys
  An alternative to the mouse which provides keyboard-based explicit control of cursor movement and all mouse button press and release events.

ToggleKeys
  Indicates locking key state with a tone when pressed; for example, Caps Lock.

BounceKeys
  Requires a delay between keystrokes before accepting the next keypress so users with tremors can prevent the system from accepting inadvertent keypresses.

### Guideline

    Recommended

in:

  Application keymappings do not conflict with existing system-level key mappings reserved for access features in the X Windows server as shown in Table 10_6 . See link .

## Resources for More Information on Accessibility

For more information about software accessibility, consult the following organizations, conferences, and books.

### Organizations

    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 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-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.

### Conferences

    CSUN
    Conference on Technology and Persons with Disabilities
    Every spring in Los Angeles, California
    (818) 885-2578
    Closing the Gap
    Conference on Microcomputer Technology in Special Education and Rehabilitation
    Every fall in Minneapolis, Minnesota
    (612) 248-3294

### Bibliography

Brown, Carl. Computer Access in Higher Education for Students with Disabilities, 2nd Edition. George Lithograph Company, San Francisco. 1989.

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.

Generated with CERN WebMaker