I recently sat through a discovery call with a client who could not work out why the complaints kept coming. They had spent thousands on an “AI accessibility overlay” and the local deaf community was still telling them the site did not work. Checkout was a mess, and their only support channel was a phone number. A script tag cannot fix a broken process. Deaf-friendly design is an architecture decision, and no amount of CSS bolted on afterwards covers for it.
Years ago I would throw auto-generated captions at every video and move on. That was a mistake. Auto-captions get things wrong often enough to be dangerous. Deafness is also a spectrum rather than a single condition: it runs from slight loss, where someone misses around 10% of speech, through to profound loss where a car horn barely registers. So if your site announces a successful form submission with a “ding” and nothing else, a large part of your audience never hears it.
Sign language is not the whole story
Only about 1% of deaf people in the US use sign language, and there is no universal version of it. A signer from London may not follow a signer from New York at all. So when you plan accessible UX research, remember that for many deaf users the written language on your site is a second language. They process information visually and spatially first.
Plenty of developers assume a transcript is enough. But a transcript that never says who is speaking, or skips non-spoken sounds like [heavy rain] or [tense music], strips the context out. It reads like a movie script with all the character names redacted.
Practical dev steps for deaf-friendly design
On a WooCommerce shop the usual sticking point is the phone field. Making it required is the quickest way to lose a deaf customer: they are not going to call you, and they do not want you calling them. Give people more than one way to get in touch, so SMS, email or live chat. I normally make the phone field optional and add a preferred contact method dropdown to the checkout. Small change, and it buys a lot of trust.
/**
* bbioon_make_phone_optional
* Removes the 'required' attribute from the WooCommerce billing phone field.
*/
add_filter( 'woocommerce_billing_fields', 'bbioon_customize_billing_fields', 20 );
function bbioon_customize_billing_fields( $fields ) {
// Make phone optional for deaf-friendly design
$fields['billing_phone']['required'] = false;
// Add a preference field for communication
$fields['billing_contact_preference'] = array(
'type' => 'select',
'label' => __('Preferred Contact Method', 'bbioon'),
'required' => true,
'class' => array('form-row-wide'),
'options' => array(
'email' => __('Email', 'bbioon'),
'sms' => __('SMS / Text', 'bbioon'),
'none' => __('No Phone Calls', 'bbioon'),
),
);
return $fields;
}Haptic feedback is worth adding too. In a progressive web app (PWA) you can use the Vibration API to signal an error or a success. A short pulse is a physical cue that still lands where an audio cue would not. The official WCAG guidelines cover how to handle non-text content properly.
Inclusive interfaces in practice
- Drop phone-only contact: always offer a text-based alternative.
- Visual indicators: a countdown timer that ends in a beep needs a flash or a bold border change as well.
- Human captions: use a service like Ava or a professional transcriber instead of pure AI.
- Transcript placement: keep transcripts on the page rather than buried in a separate PDF, which helps both SEO and usability.
Projects go wrong when accessibility is left as a post-launch task. You end up with a brittle codebase that breaks every time a core plugin updates. WordPress core accessibility has gone the other way, moving to native improvements instead of patches. For the lived experience behind all of this, read the original research on designing for deaf people at Smashing Magazine.
This gets complicated quickly. If you are tired of debugging someone else’s mess and want a site that is genuinely inclusive and works, drop me a line. I have probably seen your problem before, and I can fix it without the overlay snake oil.
The short version
Legal compliance is the low bar. Mostly this is about not being a jerk to your users, and a deaf-friendly design ends up helping everyone. The person ordering from your shop on a noisy train needs those captions. So does the person reading in a quiet library who needs text-based support instead of a phone call. That is just good design.
