EZUD Designing for Deaf and Hard of Hearing Users
Designing for Deaf and Hard of Hearing Users
The World Health Organization estimates that over 430 million people worldwide have disabling hearing loss, with that number projected to reach 700 million by 2050. Deaf and hard-of-hearing (DHH) users experience digital products primarily through their visual channel. When audio content lacks text alternatives, when alerts rely on sound alone, and when interfaces assume all users can hear, DHH users are excluded from functionality that hearing users take for granted.
Understanding the Spectrum
Hearing loss ranges from mild to profound and may be congenital, acquired, or age-related. Different users have different needs:
- Deaf users (culturally Deaf): Often use sign language as their primary language. Written text is a second language, and reading comprehension levels vary. Complex written content is not equivalent to plain-language content.
- Hard-of-hearing users: Have some hearing but may miss audio content in noisy environments, at certain frequencies, or at low volumes.
- Late-deafened users: Acquired deafness after learning spoken language. Typically comfortable with text and do not use sign language.
- Age-related hearing loss: Gradual high-frequency hearing loss affecting nearly one-third of people over 65.
WCAG Requirements for Hearing Accessibility
| Criterion | Level | Requirement |
|---|---|---|
| 1.2.1 Audio-only/Video-only | A | Transcripts for audio-only content |
| 1.2.2 Captions (Prerecorded) | A | Synchronized captions for video |
| 1.2.4 Captions (Live) | AA | Real-time captions for live audio |
| 1.2.6 Sign Language | AAA | Sign language interpretation for video |
| 1.4.2 Audio Control | A | Mechanism to pause/stop audio that plays automatically |
For detailed captioning standards, see our video captioning and audio descriptions guide.
Design Strategies
Captions and Transcripts for All Audio
This is the baseline. Every video needs synchronized captions. Every audio file (podcast, voice message, audio tutorial) needs a transcript. Auto-generated captions are a starting point but require human review — accuracy below 99% introduces confusion and errors for users who rely on them entirely.
Caption quality matters:
- Include speaker identification.
- Include non-speech audio cues: [applause], [phone ringing], [music: tense orchestral].
- Time captions to speech accurately (within 1-2 frames).
- Limit to two lines per frame with natural phrase breaks.
Visual Alternatives to Audio Cues
Any information conveyed through sound must also be conveyed visually:
| Audio Cue | Visual Alternative |
|---|---|
| Error beep | Red border + error icon + error text |
| Notification chime | Visual badge, banner, or toast notification |
| Timer alarm | Flashing indicator or on-screen countdown |
| Voice assistant response | On-screen text response |
| Incoming message sound | Visual notification + vibration (mobile) |
Do not rely on sound as the sole alert mechanism. This parallels the principle of not relying on color alone — redundant sensory channels ensure information reaches all users.
Visual Communication of Status
Progress indicators, loading states, and confirmations should be visible without audio:
- Upload progress: visible progress bar with percentage.
- Form submission: visible success message, not just an audio confirmation tone.
- Chat: visual “typing” indicator, message delivery confirmation.
Use aria-live regions to ensure these visual updates are also announced to screen reader users, who may be DHH users with additional visual impairments.
Plain Language and Visual Structure
For culturally Deaf users whose first language is a sign language, written text (especially dense, complex text) is a comprehension barrier. Apply cognitive load reduction principles:
- Use short sentences and common words.
- Support text with images, diagrams, and icons.
- Structure content with clear headings, bullet lists, and visual hierarchy.
- Consider providing sign language video content for critical information (WCAG AAA, SC 1.2.6).
Communication Features
If your product includes communication features:
- Chat/messaging should be available alongside or instead of voice calls.
- Video calling should support sign language quality: minimum 24fps video, low latency, ability to see hands and face clearly. Compression artifacts that blur hand movements make sign language unintelligible.
- TTY/RTT support for phone-based services (real-time text, compatible with relay services).
- Customer support should offer text-based channels (live chat, email) with response times comparable to phone support.
Auto-Playing Audio
WCAG SC 1.4.2 (Audio Control, Level A) requires that if any audio plays automatically for more than 3 seconds, the user must be able to pause, stop, or control the volume independently of the system volume.
Best practice: do not auto-play audio at all. If auto-play is necessary (promotional video on landing page), provide a visible, prominently placed pause/mute button and default to muted.
Testing for Hearing Accessibility
- Mute your device and navigate every user flow. Is all critical information available visually?
- Review captions on all video content. Are they accurate, synchronized, and complete (including non-speech audio)?
- Check all alert patterns. Does the product use any sound-only alerts? Add visual alternatives.
- Test communication features. Can a DHH user complete customer support interactions, onboarding flows, and collaborative features without voice?
- Verify with users. Include DHH participants in usability testing — their perspectives reveal issues that technical audits miss.
Key Takeaways
- Captions for video and transcripts for audio are the non-negotiable baseline.
- Never rely on sound as the sole indicator of information, status, or alerts.
- Support text-based communication alongside voice for all interactive features.
- Apply plain language and visual structure to reduce reading comprehension barriers for sign language users.
- Test by muting your device and completing every user flow.
Next Steps
- Implement video captioning that meets quality standards.
- Design visual alert systems using error handling patterns that do not depend on audio.
- Review the universal design framework for how hearing accessibility fits into the broader strategy.
Sources
- WCAG 2.2 SC 1.2.2 Captions (Prerecorded) — The captioning requirement for prerecorded content.
- W3C WAI: Making Audio and Video Accessible — Multimedia accessibility guidance for deaf and hard-of-hearing users.
- WebAIM: Auditory Disabilities — Guide to designing for hearing-related disabilities.
- Deque University: Multimedia Accessibility — Checklist for accessible multimedia content.
Hearing loss statistics from the World Health Organization. WCAG requirements from Success Criteria 1.2.1, 1.2.2, 1.2.4, 1.2.6, and 1.4.2. Communication accessibility guidance adapted from the Hearing Loss Association of America (HLAA) and W3C WAI.