The web increasingly provides both a rich visual and audio experience. In this article, we'll define auditory disabilities and talk about web development strategies for improving accessibility for users with hearing impairment.
The internet has done more than transform the way people with auditory disabilities access information. It has enabled them to take part in a system of global communication. However, developers often don’t consider individuals who are deaf; these individuals still encounter barriers when trying to access information on the web. Developers often regard web accessibility as nothing more than adhering to guidelines that ensure sites work with screen readers for the blind. This failing is understandable given how many of us think of the web as a visual medium, but is it?
The web consists of information presented as graphics, video, audio, animation, or text. While our most common experience with web content is visual, increasingly content on the web is a rich visual and audio experience.
Perhaps the most compelling reason to make your site accessible to those with hearing disabilities is that there are negative social implications for those with different types of hearing loss. For example, those with high-tone hearing loss have a more difficult time understanding women’s voices, and the same is true with men’s voices for those with low-tone hearing loss. Likewise, hearing loss has a tremendous social impact on aging individuals. It is thus important to mitigate these social ramifications by making your web content as accessible as possible to these individuals.
Developers should consider accessibility in the context of all disabilities. This article explores useful strategies that help improve accessibility in apps and products to those with hearing loss. Catering to this broad demographic shows respect through inclusion, but it’s also a smart business strategy. Despite the wealth of available assistive technologies, a web application that’s short on accessibility features still presents frustrating problems for users with impairments.
Before we look at strategies to improve the internet for individuals with auditory disabilities, let’s first examine the disabilities themselves: specifically, the degrees and classifications of hearing loss. Although deafness is often considered an all-or-nothing condition, many individuals have degrees of functional hearing loss, classified as mild, moderate, severe, and profound. Those who identify as deaf usually have either acute or profound hearing loss, where people with lesser degrees of hearing loss are commonly referred to as hard-of-hearing.
Mild hearing loss refers to the inability to hear sounds below about 30 decibels. Speech for these individuals can be difficult to understand, especially in the presence of background noise. Those with moderate hearing loss are unable to hear sounds below about 50 decibels; to compensate, they may require a hearing aid. Severe hearing loss is the inability to hear sounds below approximately 80 decibels, and while hearing aids can help some of these individuals, they may be insufficient. The complete inability to hear, or an inability to hear sounds below about 95 decibels, is referred to as profound hearing loss. Along with those who have severe hearing loss, many individuals with profound hearing loss communicate principally through sign language; others rely on lip-reading.
Just as hearing loss has its different degrees, there are also classifications of auditory impairment. Conductive hearing loss is the result of damage to or blockage of the moving parts of the ear which leads to the inability of the inner ear bones to vibrate correctly, preventing the proper detection of auditory information. Neural hearing loss (nerve deafness) occurs when the hair cells of the inner ear are damaged, which prevents the associated nerves from properly transmitting auditory information to the brain for processing.
High-tone hearing loss, as its name implies, refers to the inability to hear high frequencies, just as low-tone hearing loss means that low frequencies are inaudible. Deaf-blindness is the condition of being both deaf and blind; those who are deaf-blind often communicate by sign language, but they feel the signs the other speaker is making. And when accessing web content, they generally use refreshable braille displays that allow access to all the web page’s textual content, including alternative text for images.
Improving accessibility to the hearing impaired in your applications begins by examining how these users navigate the web. The strategies people with auditory disabilities use vary according to the type and extent of their disability and the individual’s preferences, but at minimum, provide transcripts for audio-only content, and provide both captions and transcripts for multimedia content, i.e., video content with audio.
Providing transcripts is a good idea in itself: text content is easy to skim, not to mention highlight, and it also offers SEO advantages for your site or app. Additionally, those who like to take notes have an easier time doing so with text content available.
With video content, the most effective way to make multimedia content accessible to persons with hearing disabilities is including captions and subtitles.
Like transcripts for audio-only content, captions and subtitles benefit the public at large. Many viewers of your video content are likely to be watching on their phones in a public place, and so have the sound muted. This is true for popular platforms like Facebook and Instagram, and it’s likely to become the norm in the future.
Offering sign language is secondary to the other methods of content accessibility, but it remains a valid consideration. It may not be possible for those who communicate primarily in sign language to read and understand text at the rate it is presented in captions.
Providing sign language presentation of audio information is a way to make content accessible to these individuals. One universally compatible way of doing this is to embed a video of the sign language interpreter in the video stream.
However, this has a few disadvantages. One is technical: including sign languages leads to a lower resolution image that cannot be enlarged without enlarging the entire image. A deeper issue is a linguistic one: American Sign Language (ASL) differs from British Sign Language (BSL) and Australian Sign Language (Auslan), and is different from the sign languages in Europe and Asia.
Different sign languages are in use around the world, and while that presents problems more related to internationalization than accessibility, the fact that those who can read the same spoken language (e.g., English) sometimes use and understand profoundly different sign languages presents a problem of disability access. Still, including sign language feeds is an option to consider.
Besides transcripts and captions for those with hearing impairment, there are more accessibility considerations to keep in mind as a web developer.
First, don’t rely on sounds alone to get the user’s attention; instead, use a combination of sound and visual elements. Though this principle applies to alerts and notifications, it also naturally extends to providing support over email or text chat, as opposed to forcing customers to call a phone number (even if you offer support over TTY/TDD).
Next, make two-factor authentication friendly and fully accessible to those with auditory disabilities by not requiring a phone for initial setup, reset or validation.
Third, increase the distinguishability of your content by excluding background sounds, making it easier for those who are hard of hearing to discern your content. If this is not an option, include background sounds that a user can turn off, or background sounds that are at least 20 decibels lower than the foreground speech content. For those who are completely deaf or cannot audibly discern your content, making your content visually distinguishable by, for example, increasing contrast and enlarging text, is an important consideration.
Options for making your application or site accessible to users with auditory impairments don’t end with these best practices. We encourage you to delve into the full potential of true accessibility when developing web apps. Reading the Web Content Accessibility Guidelines (WCAG) 2.0 at the World Wide Web Consortium (W3C) website is a great place to start.
Most of the work required to make your website accessible to persons with hearing disabilities consists of providing text-based alternatives for video and audio content. However, you may discover other, smaller details in your website or product experience that also present difficulties to those who can’t hear or hear well. Developers committed to making their content more accessible should take this goal into account as early as possible when planning a project. Although you can apply small changes after development is complete, you can’t address everything required for accessibility by a technical change.
It’s, therefore, crucial to educate your team about all types of disabilities your users might have so that they can design and build software with accessibility in mind. That, in turn, is an essential step in helping the web become a friendlier and more welcoming place for those with auditory disabilities. Along with providing resources like transcripts and captions, clarity in your content can make a profound difference for users with auditory disabilities.
We have created a comprehensive whitepaper on accessibility for developers that covers everything from laws to coding to testing.
Download the whitepaper: Accessibility for Developers
One easy way to make sure that you are creating accessible web apps is to start with components from the Kendo UI libraries. Our components are all WCAG complaint and give you great functionality from grids and charts to schedulers and pickers. Get a head start on your app's UI and a head start on accessibility compliance at the same time.
Learn more about: Kendo UI
Chris Ward explains cool tech to the world. He is a technical writer and blogger. He has crazy projects in progress and will speak to anyone who listens. You can talk to him! :)
Subscribe to be the first to get our expert-written articles and tutorials for developers!