Making Educational Software Accessible
Design Guidelines; Including Math & Science Solutions
image map with 5 links; see bottom of page for text links.
http://main.wgbh.org http://ncam.wgbh.org http://ncam.wgbh.org/cdrom/index.html Table of Contents Credits



For People Who Are Blind | For People With Low Vision | For People With Color Blindness | For People Who Are Hard-of-Hearing or Deaf | For People With Physical Disabilities | For People With Language or Cognitive Disabilities | For People In General

Disabilities, Functional Limitations, and Accessibility Tips

This section provides an introduction to several types of disabilities and the functional limitations they cause for computer users. Accessibility tips describe general strategies for meeting the needs of these users. See www.trace.wisc.edu/world/computer_access/software for a comprehensive guide to creating accessible software.

This section is adapted with permission from a previous publication of the Trace R&D Center, the Application Software Design Guidelines published at www.trace.wisc.edu/docs/software_guidelines/ software.pcs/cover.htm and written in 1994.

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 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 text-to-speech synthesizer or refreshable braille display.

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 possible to draw and erase all on-screen text and to display all cursors and pointers.
  • using the system standard controls whenever possible.
  • drawing tools in toolbars, palettes, and menus as separate items (rather than one big graphic). This makes it possible to identify the number, location, and shape of the individual tools so they can be identified and named.

The compatibility of software can also be increased with screen readers by:
  • using a special technique to make the text known to screen reading software if the text is embedded in a graphic image.
  • dragging system cursors with you (even if invisible) when custom highlight or focus techniques are used.
  • using consistent or predictable screen and dialog layouts.
  • avoiding use of help balloons that disappear if the focus changes unless there is a way to lock them in place so that the focus (e.g., the cursor) can be moved to read them.
  • using single column text whenever possible.
  • giving controls logical names, even if the name is not visible on the screen. (Screen readers can access this information and use it to describe the type and function of the control on the screen.)
  • provide 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 visible or invisible cues. (Screen readers can "see" text that is written to screen an invisible color.)
  • avoid non-redundant graphic tool bars.

Finally, documentation and training materials can be more accessible when:
  • all documentation and on-line help is designed to be understood by reading the text only (e.g., information presented in pictures and graphics is also presented with a description in text).
  • synchronized running audio descriptions for all information is presented as an animated graphic or movie.

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 the visual field) 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, the direct accessibility of software can increase when the user can adjust the fonts, colors and cursors in a program to make them more visible.
  • high contrast between text and background is used.
  • text is not placed over a patterned background where the two might interfere with each other.
  • a consistent or predictable layout for screens and dialogs is used within the program.
  • access to tools, etc., is provided via a menu bar.
  • the recommended line width information is used when drawing lines (if such information is provided by the system).
  • the user can zoom in to view portions of the screen in more detail.

In addition, the compatibility of software with low-vision access features and software can increase when:
  • the system pointers are used whenever possible, as well as the system caret or insertion bar if available.
  • a highlight or focus indicator is included to drag the system cursor even if it is invisible. This makes tracking the focus much easier for screen enlargement or "pan and zoom" features.
  • the operating system has a supported High Contrast setting.
  • users are not required to simultaneously monitor two events occurring far apart on the screen.
For People With Color Blindness
The accessibility of software can increase when:
  • color coding is redundant with other means of conveying information.
  • any program can operate in monochrome mode.
  • colors differing in darkness as well as in color are used.

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, the accessibility of software to users with hearing impairments can increase when:
  • all auditory information is also provided in a visual form.
  • all visual cues are noticeable if one is not looking directly at the screen.
  • a ShowSounds feature is supported. (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.)

In addition, product support people must be reachable via text telephones (TTYs).

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 in 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, accessibility of software can increase (both directly and through compatibility with assistive technologies) when timed responses (less than 5-8 sec.) are avoided, or when the response time can be changed.
  • Keyboard access to all toolbars, menus, and dialog boxes (whose functions are not also in the menu) is provided.
  • Access features built into the operating system (e.g. StickyKeys, SlowKeys, Key Repeating etc.) are not disabled

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, the accessibility of software can increase when:
  • all messages and alerts stay on screen until they are dismissed.
  • language is as simple and straightforward as possible, both on screen and in the documentation.
  • simple and consistent screen layouts are used.

In addition, because print disabilities are more common among people with language and cognitive impairments, accessibility of software increases when it is compatible with screen reading software. (See the section titled "For People Who Are Blind.")

For People In General
Finally, the overall accessibility of software increases when:
  • documentation is available in electronic form, accessible by screen reading software thus making it accessible for people who cannot handle or read printed manuals.
  • product support staff are aware of disability access issues and are aware that people with disabilities routinely use software products.
  • particular product support staff specialize in handling incompatibility of software and assistive technologies. (All support people should be able to handle regular product use questions from people who have disabilities, but dedicating a few people to deal with incompatibility problems allows them to become more familiar with issues and work-arounds.)
  • any access or compatibility problems identified by product support people are forwarded to product designers (and lower trigger levels are set for incidence vs. priority for fixing).




_ NSF Logo and link to NSF web site   WGBH logo and link to WGBH web site