| A serious topic that falls under the area of usability testing is that of accessibility testing or testing for the disabled. A 1997 government Survey of Income and Program Participation (SIPP) used by the U.S. Census Bureau found that about 53 million people (nearly 20% of the population) in the country had some sort of disability. Table 11.1 shows a more detailed breakdown. Table 11.1. People with DisabilitiesAge | Percentage of People with Disabilities |
|---|
024 | 18% | 2544 | 13% | 4554 | 23% | 5564 | 36% | 6569 | 45% | 7074 | 47% | 7579 | 58% | 80+ | 74% |
Cutting the data another way, reveals that 7.7 million people have difficulty seeing the words and letters in a newspaper. 1.8 million people are legally blind and 8 million people have difficulty hearing. With our aging population and the penetration of technology into nearly every aspect of our lives, the usability of software becomes more important every day. Although there are many types of disabilities, the following ones make using computers and software especially difficult: Visual impairments. Color blindness, extreme near and far sightedness, tunnel vision, dim vision, blurry vision, and cataracts are examples of visual limitations. People with one or more of these would have their own unique difficulty in using software. Think about trying to see where the mouse pointer is located or where text or small graphics appear onscreen. What if you couldn't see the screen at all? Hearing impairments. Someone may be partially or completely deaf, have problems hearing certain frequencies, or picking a specific sound out of background noise. Such a person may not be able to hear the sounds or voices that accompany an onscreen video, audible help, or system alerts. Motion impairments. Disease or injury can cause a person to lose fine, gross, or total motor control of his hands or arms. It may be difficult or impossible for some people to properly use a keyboard or a mouse. For example, they may not be able to press more than one key at a time or may find it impossible to press a key only once. Accurately moving a mouse may not be possible. Cognitive and language. Dyslexia and memory problems may make it difficult for someone to use complex user interfaces. Think of the issues outlined previously in this chapter and how they might impact a person with cognitive and language difficulties.
Legal Requirements Fortunately, developing software with a user interface that can be used by the disabled isn't just a good idea, a guideline, or a standardit's often the law. In the United States, three laws apply to this area and other countries are considering and adopting similar laws: The Americans with Disability Act states that businesses with 15 or mores employees must make reasonable accommodations for employees, or potential employees, with disabilities. The ADA has recently been applied to commercial Internet websites, mandating that they be made accessible to the public who uses them. Section 508 of the Rehabilitation Act is very similar to the ADA and applies to any organization that receives federal funding. Section 255 of the Telecommunications Act requires that all hardware and software that transfers information over the Internet, a network, or the phone lines be made so that it can be used by people with disabilities. If it's not directly usable, it must be compatible (see Chapter 8, "Configuration Testing," and Chapter 9, "Compatibility Testing") with existing hardware and software accessibility aids.
Accessibility Features in Software Software can be made accessible in one of two ways. The easiest is to take advantage of support built into its platform or operating system. Windows, Mac OS, Java, and Linux all support accessibility to some degree. Your software only needs to adhere to the platform's standards for communicating with the keyboard, mouse, sound card, and monitor to be accessibility enabled. Figure 11.7 shows an example of the Windows accessibility settings control panel. Figure 11.7. The Windows accessibility features are set from this control panel. 
If the software you're testing doesn't run on these platforms or is its own platform, it will need to have its own accessibility features specified, programmed, and tested. The latter case is obviously a much larger test effort than the first, but don't take built-in support for granted, either. You'll need to test accessibility features in both situations to make sure that they comply. NOTE If you're testing usability for your product, be sure to create test cases specifically for accessibility. You'll feel good knowing that this area is thoroughly tested.
Each platform is slightly different in the features that it offers, but they all strive to make it easier for applications to be accessibility enabled. Windows provides the following capabilities: StickyKeys allows the Shift, Ctrl, or Alt keys to stay in effect until the next key is pressed. FilterKeys prevents brief, repeated (accidental) keystrokes from being recognized. ToggleKeys plays tones when the Caps Lock, Scroll Lock, or NumLock keyboard modes are enabled. SoundSentry creates a visual warning whenever the system generates a sound. ShowSounds tells programs to display captions for any sounds or speech they make. These captions need to be programmed into your software. High Contrast sets up the screen with colors and fonts designed to be read by the visually impaired. Figure 11.8 shows an example of this. Figure 11.8. The Windows desktop can be switched to this high contrast mode for easier viewing by the visually impaired. 
MouseKeys allows use of keyboard keys instead of the mouse to navigate. SerialKeys sets up a communications port to read in keystrokes from an external non-keyboard device. Although the OS should make these devices look like a standard keyboard, it would be a good idea to add them to your configuration testing equivalence partitions.
For more information about the accessibility features built into the popular OS platforms, consult the following websites: |
