But Can They Hear It?
George O. Allen
Summary: Describes how visual sound cues can be used in your application as an alternative or supplemental means of conveying important information to the user. (2 printed pages)
In an earlier article, we discussed the use of color and how some uses of color impact persons with visual impairments. (See "But Can They Read It?" in the July/August 1998 issue of MSDN News.) Many of the issues surrounding the use of color have been covered in the Designed for Windows Logo program since its inception. For the Designed for Windows 2000 Logo requirements, a new requirement specifies that a visual element be used in concert with application-generated sounds.
Your application should not convey any important information by sound alone. If sound alone is the default method for conveying the information, the application should provide an option to convey this information by other means.
Why Visual Sound Cues?
Why should you care about visual cues? In certain environments, such as a noisy factory floor, or for certain users, such as the hard of hearing, an application-generated sound cue is useless. Employing a visual cue in these circumstances alerts a user to an event that requires their input.
Approximately two million people in the United States alone have some form or level of hearing impairment. Though a textual or graphical environment is accessible to a hard of hearing user in most cases, when user intervention events occur, sound alone does not catch their attention and draw it to the event. Some kind of visual cue must occur to focus their attention to the event so they can intervene. The same holds true with non-hard of hearing users in a noisy environment or on a computer without sound capability.
There are a variety of means of using visual cues to identify sound events. The determination of how you implement it in your application is up to you. In general:
- Don't convey important information by sound alone, because some people will not be able to hear it. Use visual cues to enhance, emphasize, or reiterate events requiring user intervention.
- Let the user customize to meet their needs by responding to SPI_GETSHOWSOUNDS.
Respond to ShowSounds
When a user selects the ShowSounds option in Control Panel, any audibly cued information in your application must be conveyed visually. This option is set using the Accessibility Options section in Control Panel. You can determine the current value of the ShowSounds option by using the SystemParametersInfo function to query SPI_GETSHOWSOUNDS.
When the ShowSounds option is selected, your application must provide visual equivalents of any information that is normally provided by sound alone. If the ShowSounds option is selected when your application starts, your application may ask the user if they want to display these additional visuals. This option is provided in cases where the user may already be expecting audible events and chooses to accept control over the events without being prompted.
Your application is not required to display visual equivalents of music or other sounds that convey no information. However, you are required to display a visual indication that such sounds are playing. This display is optional and does not have to be on by default, but it must be on when the ShowSounds option is enabled.
Because of the dependence on audio, games are exempt from this requirement. It is strongly recommended that games provide an option to display a visual equivalent of any information that is normally conveyed by sound alone. This recommendation stems from the fact that hard of hearing users cannot use most games because cues to upcoming action, such as the approach of an enemy, are usually represented only via audio. Providing an option to have a visual cue would open up these games to new users.
Closed captioning or synchronized highlighting is recommended for all audio and video content that conveys information and is longer than a few seconds. Closed-captioning is supported by Microsoft® Windows Media Player™ version 5.2 or later.
George Allen is Technical Program Manager in the Accessibility and Disabilities Group at Microsoft Corporation.