Why Building for Both Blind and Deaf Users Forces Better Design

Most products pick a channel and lean on it. Visual apps lean on layout; voice assistants lean on audio. EBITH cannot do either, because it serves both blind and deaf users — and around 450,000 people in the UK who are deafblind and belong to neither group cleanly.

Every design shortcut that depends on one sense is unavailable to us. That constraint has been the most useful thing about the project.

The constraint, stated precisely

Take any interface decision and run it through two filters:

• Filter A: does this still work if the user cannot see the screen?
• Filter B: does this still work if the user cannot hear any output?

A toast notification fails A. An audio confirmation chime fails B. A red border on an invalid field fails both, for different reasons — a blind user never sees it, and a colourblind user (about 1 in 12 men) may not distinguish it either.

What survives both filters is a small, disciplined set of patterns. That set turned out to be the good interface all along.

What survives

Every state has three representations

Not one, translated. Three, designed:

State	Visual	Audio	Haptic
Sign recognised	Label + confidence, 32pt	Spoken label	Single short pulse
Low confidence	Amber outline + "unclear" text	"Not sure — sign again"	Double pulse
Obstacle ahead	Bounding box + distance	Spatialised tone, left/right	Escalating pulse rate
Listening	Animated meter	Rising two-tone	Continuous light pulse

The haptic column is the one teams skip, and it is the one that carries the product for deafblind users. It is also, unexpectedly, the channel our sighted-and-hearing testers liked most — a pulse in the pocket beats a chime in a noisy street for everybody.

Note the second row. "Low confidence" is a state we designed for, not an error we hid. Amber outline and the word "unclear" and a distinguishable pulse pattern — because WCAG 1.4.1 is right that colour must never be the only carrier, and because a user who cannot see the amber still needs to know the system is unsure.

Speech is the interface, not a feature bolted on

If a blind user must find a button to start a task, the button is the failure. EBITH's primary loop is voice-first:

• Start states are announced, not displayed.
• Every action has a spoken command and a physical gesture that does not require aim — a two-finger double-tap anywhere on screen, not a target you have to hit.
• Nothing important is behind a swipe direction the user cannot preview.

Building voice-first exposed something we did not expect: it forced us to name every state out loud. You cannot write an announcement for a screen you have not thought through. Several half-designed flows collapsed the moment we tried to describe them in a sentence.

Latency is an accessibility property

A sighted user reads a spinner and understands the system is working. A blind user gets silence, which is indistinguishable from a crash.

That reframed our performance budget as a correctness requirement rather than a nice-to-have:

• Under 100ms — feels instant, no feedback needed.
• 100ms to 1s — needs an audible or haptic "working" signal.
• Over 1s — needs a progress announcement with an estimate, or the design is wrong.

Our 31ms on-device inference is not a benchmark we chase for its own sake. It is what keeps the interaction inside the first band, where no explanation is necessary. Cloud inference would put every recognition into the second band on a good connection, and into "did it crash?" on a bad one.

Text sizes that do not need a settings page

Our minimum body size is 18px and headline states render at 32px and above. Everything reflows to 200% zoom without horizontal scrolling, per WCAG 1.4.10.

This started as a partial-sight requirement. It ended up being what makes the app usable one-handed, at arm's length, in bright sunlight — which is the actual condition of someone holding a phone up to translate a conversation on a pavement.

The ethics we had to settle first

AI in assistive technology carries risks that a photo filter does not. Three questions we answered before writing production code:

1. What happens when the model is wrong?

Not if. Our BSL model runs at 92.45% accuracy — roughly one sign in thirteen is misclassified. In a GP appointment, a confidently wrong translation is worse than no translation, because the human on the other side has no way to detect the error.

So the system is designed to refuse. Below 85% confidence, or when consecutive predictions disagree, EBITH surfaces nothing and asks for a repeat. This drops the recognition rate to about 88% of attempted signs and raises precision on what it does report to 97.3%.

We accept a less impressive demo in exchange for a system that fails loudly rather than quietly. Any assistive tool that will not tell you it is unsure is not safe to depend on.

2. Who sees the camera feed?

Nobody. Not us, not a cloud provider, not a subprocessor.

Every model runs on the device. The 255KB TFLite file ships inside the app bundle. There is no inference endpoint, no telemetry of recognised signs, no opt-out to configure because there is nothing to opt out of.

This is not primarily a GDPR position, though it helps. It is that the camera is pointed at private medical conversations, at children in classrooms, and at the inside of people's homes. The only defensible architecture is one where the sensitive data never leaves the device — and the honest version of that promise is one that holds with the phone in aeroplane mode.

3. Does this replace a human, or cover the gap where there is no human?

We are explicit internally: EBITH does not replace interpreters, and any pitch that implies it does is a pitch we will not make.

A qualified BSL interpreter handles nuance, register, regional variation, and repair in conversation at a level no 93-sign model approaches. Deaf people have fought for decades for the right to interpreter provision, and a technology company arguing that an app is a cheaper substitute would be handing budget-holders an excuse to cut it.

What EBITH covers is the time when no interpreter is present and none was ever going to be: the unscheduled ninety seconds at a reception desk, the question a classmate asks between lessons, the delivery driver at the door. Nobody books an interpreter for those. That is the gap, and it is large enough.

The generalisation

The pattern here is not new — it is the curb-cut effect, and the examples are well worn because they are true. Kerb ramps built for wheelchair users serve pushchairs, delivery trolleys, and anyone with a suitcase. Captions built for deaf viewers are used by the majority of people watching video in public.

What is less often said is why it works, and it is not luck. Designing for a constrained user is a forcing function against ambiguity. You cannot rely on a user inferring meaning from a layout they cannot see, or from a tone they cannot hear. Every piece of information has to be stated, in more than one channel, unambiguously.

That is just a description of a clear interface.

The three sensory channels, the refuse-when-unsure behaviour, the latency budget, the 18px floor — none of these are accessibility accommodations bolted onto a design. They are the design. We arrived at them because we had no other option, and we would keep them for a product with no disabled users at all.

---

This site is built to the same standard it describes: WCAG 2.1 AA, full keyboard operation, honoured reduced-motion preferences, no information carried by colour alone. If any of it fails for you, that is a bug — tell us at hello@devsandvisuals.com.