1.7 Ensure that all information can be perceived by users with restricted or no hearing
Users who are deaf or hard of hearing should be able to perceive all of the outputs from the application. Where possible, audible information should be delivered in a form that users who are hard of hearing can hear. Where this is not possible, and for users who are profoundly deaf, an alternative form that they can perceive should be made available and it should provide the same information.
If audio output is used to present information, users who cannot hear well enough will not be able to understand the information being given. If audio output is used to alert the user to an incident, users who cannot hear the alert will not know the incident has occurred. Not being able to hear audio outputs or hear them well enough to understand them is often due to a combination of poor hearing, inadequate sound quality and background noise. So by increasing the sound quality and taking steps to reduce background noise, even users with some hearing impairment will be able to understand the information.
Directions and Techniques
Provide adequate quality sound
Complex natural sounds, such as music and speech, should be recorded using professional equipment and adequate digital sampling rates. Speech output can be achieved using either pre-recorded audio or speech synthesis. If possible, use digitised pre-recorded speech which has been recorded in a professional studio and spoken by a trained announcer. Speech synthesis, whilst more flexible, is often of much poorer quality and may be difficult to understand for some users and in noisy environments.
For all audible cues, provide corresponding visual cues
Supplement audible alerts with simultaneous corresponding visual cues, such as flashing icons or window borders. Be careful not to conflICT with built-in operating system accessibility tools, such as Sound Sentry, which perform this function.
React to status of the "Show Audio" option if included in the operating system
Some operating systems provide a user-selectable "Show Audio" option (it may not have this name), which enables the user to request that all sounds should be accompanied by a visual event, including a caption for any spoken text. Application programs should react to this option by generating their own visual equivalents.
How you could check for this:
There are no specific test methods recommended for this guideline.