2003 Conference Proceedings

Go to previous article 
Go to next article 
Return to 2003 Table of Contents 


Debbie Cook
Organization: AccessIT
Address: Box 357920, University of Washington
City: Seattle
State/Province/Region: WA
Zip/Postal Code: 98195
Day Phone: 866-968-2223
TTY: 866-866-0162
Email: debcook@u.washington.edu

Assistive technology such as screen readers and screen magnification software for people who are blind or visually impaired, voice recognition and alternative keyboards or mice for people with mobility limitations, and products that synchronize screen text with synthetic speech for individuals with learning disabilities, etc. have potential to enhance access for students with disabilities to the instructional software increasingly being used in classrooms and distance learning environments. However, it often takes more than assistive technology to make these software environments accessible. If teachers and technology planners do not consider accessibility features when purchasing software, they are likely to buy products which cannot work successfully with the assistive technology needed by students with disabilities. The result is frustration for teachers and students, poor accommodation of the student's needs, and limited or no access to the classroom software despite the investment in assistive technology. This problem is further complicated because software developers have often not considered accessibility for students with disabilities when designing instructional software. This means that teachers and technology specialists must take initiative to develop skills and techniques for determining whether instructional software includes necessary accessibility features to support commonly used assistive technologies. This presentation descrieds and demonstrates techniques teachers and technology specialists can use to determine whether current and future instructional software purchases meet minimal accessibility requirements for entering data and commands, tracking visual focus, use of sound, display of visual information, use of timed responses, and access to documentation.

Primary Evaluation Strategies

There are three commonly used strategies which can be used singly or in combination to evaluate accessibility of instructional software. They are: accessibility testing and verification conducted by the software developer (http://www.itic.org/policy/access_0106.htm), testing and evaluation conducted by a third party with experience conducting such evaluations, and product evaluation by teachers or technology specialists using a software accessibility checklist (e.g. http://www-3.ibm.com/able/accesssoftware.html, http://trace.wisc.edu/docs/software_guidelines/software.htm, and http://www.usdoj.gov/crt/508/archive/oldsoftware.html). This presentation discusses the applicability and practicality of each strategy as it relates to instructional software. Regardless of strategy, it is necessary for those purchasing software to understand the basic elements of accessibility in order to make good evaluation and procurement decisions.

Review of Accessibility Factors

Using existing software accessibility checklists which have been adapted to meet the unique needs for evaluating instructional software, commonly used instructional software, and popular assistive technologies we will demonstrate simple techniques for evaluating accessibility of the following factors:

Accessibility of Input for Data and Commands

Students who are unable to use the mouse need all commands and functions to be available via the keyboard. Additionally, accessibility options built into the Windows Operating System such as sticky keys, make it possible for people with a variety of disabilities to use their computer. If the instructional software does not provide keyboard equivalents for all functions or interferes with the accessibility options, some users may find their system unusable.

Tracking Visual Focus

Even when instructional software provides keyboard access, it isn't enough if you don't know where you are. When editing, for example, a blind student using a screen reader moves the focus (insertion bar) with the arrow keys. The screen reader must be able to follow the insertion bar and echo the current character, word or line. And when the user is filling out a form and encounters a radio button, check box, or edit field, the instructional software must be able to provide information about that item and it's status (checked for example) to the screen reader. Similarly, a student with low vision using a screen magnifier must be able to follow the visual focus when tabbing around a dialog box.

Accessibility of Sound

Students who are deaf or hard-of-hearing, who work in noisy environments, or who turn off sounds to avoid disturbing others may be unable to hear or distinguish sounds used to convey information in instructional software. For these users to respond to audio alerts, the alerts must also be presented visually. Some common examples are: new mail notification, beeps indicating system errors, or sounds indicating a change in status. Another critical issue is that audio content such as talking and music is not accessible to users who are deaf or hard-of-hearing. Video content such as pictures and animation is not accessible to users who are blind. Those who have hardware or environmental limitations may also be unable to use audio or video content. Therefore, important audio and video information must be provided in accessible formats such as closed captioning for audio content and video description for visual content.

Display of Information on the Screen

When instructional software conveys information only by color, students who cannot distinguish colors will not be able to use the information. For example, asking a student to press the red button does not work if the user can't distinguish the red button from other buttons on the screen. The ability to select color, contrast, size and font is also often critical for users with visual impairments. They may require high contrast between text and the background in order to read. They may even need a particular scheme, such as white text on a black background, to prevent the background from "bleeding" over and obscuring the foreground text. Many users have difficulty reading small text, seeing small objects, or targeting small objects with the mouse making flexibility important when sizing objects on the screen. Displays which flicker or flash can cause photosensitive epileptic seizures in susceptible individuals, particularly if the flash has a high intensity. This includes flashing text, turning graphics on and off or repeatedly changing between different images on the screen.

Timed Responses

Some students will have difficulty reading or responding to information if it is displayed briefly or requires a quick response time. Sometimes response delays may also be caused by the use of assistive technology such as screen readers or screen magnifiers.


Students with disabilities must have access to both documentation of product features and operation as well as specific documentation of any accessibility features provided or supported by the instructional software. At least one copy of the documentation should be available electronically in a text format such as a text file, HTML etc. This makes it easier to produce alternative formats such as Braille and is compatible with assistive technologies such as screen readers.


It will take more than simply assessing the accessibility of commercial instructional software to close the gap between software design and usability for all students. It takes an organizational commitment to accessibility in policy and practice, training in the skills necessary to make and implement good access decisions, willingness to work closely with software developers and suppliers and the ability to clearly state why accessibility matters to those you serve. Using a checklist or other strategy to evaluate the accessibility of your instructional software is an excellent placed to begin this process. This is a process that can be used by individual teachers, IT specialists, procurement officers, and students themselves to increase the likelihood that IT in schools is accessible.

Go to previous article 
Go to next article 
Return to 2003 Table of Contents 
Return to Table of Proceedings

Reprinted with author(s) permission. Author(s) retain copyright.