Bridge: The Words Were Always There
An accessible communication system built from the experience of knowing exactly what I want to say, but not always being able to make speech cooperate.
Inspiration
My name is Akshat, and I have Childhood Apraxia of Speech.
The most painful misconception about CAS is that difficulty producing speech means difficulty thinking.
The words are not missing. The motor plan is.
Childhood Apraxia of Speech is a neurological speech sound disorder that affects the brain's ability to plan and sequence the movements required for speech. A person may know exactly what they want to say, but producing it clearly and consistently can require enormous effort. Sounds may come out differently across attempts. Longer words can become harder. Rhythm, stress, and transitions between sounds may not cooperate.
ASHA currently estimates CAS in approximately one out of every one thousand children ages four through eight. It is uncommon enough to be overlooked, but common enough to represent thousands of students whose voices are routinely filtered through systems that were never designed for them.
I know what it feels like to have a complete thought and still be judged by its delivery.
People can hear hesitation and assume uncertainty. Software can hear an imperfect phrase and confidently produce a completely different sentence. A support chatbot can receive fragments, misspellings, or a failed voice transcript and conclude that the user has not provided a valid request.
Then comes the instruction that sounds simple only to someone for whom communication is effortless:
"Please rephrase your question."
That sentence is not help. It is another test.
A typical support chatbot expects a clean sentence, a recognized intent, and a predictable sequence of answers. If the user cannot satisfy those assumptions, the system begins repeating itself. It offers irrelevant options. It corrects the wrong problem. It may even prevent the user from reaching a human until they successfully explain why they need one.
The original problem remains unsolved, but now the user also has to prove that they are capable of asking for help.
Learning disabilities and communication disabilities are often treated as separate design problems. In a real classroom, they compound. A student may understand the lesson and still struggle to ask for a break, explain sensory discomfort, report a peer problem, request more time, or reach a trusted adult in the format that a digital system demands.
That became the question behind Bridge:
What if the user never had to perform clarity for the machine? What if the machine carried the burden of adapting instead?
What Bridge does
Bridge is an accessible expression layer for neurodivergent students.
The public prototype follows Maya, a fictional student in a synthetic classroom scenario. Bridge does not diagnose Maya. The scenario exists to demonstrate how a student can communicate a support need without first producing a perfect sentence.
A student can begin in three ways:
- Type any available words, including fragments, misspellings, and incomplete thoughts.
- Speak once and receive both a visible and spoken response when browser voice services are supported.
- Select "I don't know what to say" and enter a no words route built from broad, context supported choices.
Bridge preserves the student's original input. It then generates up to three possible meanings, explains when context was considered, and asks only for information that is still missing.
- If Bridge is uncertain, it says so.
- If the message does not match a supported concept, Bridge abstains.
- If the student asks for a person, Bridge does not reinterpret that request.
- If a possible safety concern appears, Bridge bypasses ordinary ranking and moves into an explicit urgent review path.
Most importantly, Bridge never selects a meaning or prepares a ticket automatically. The student confirms the interpretation, chooses between their exact words and an optional phrased version, and performs the final action themselves.
The AI has permission to suggest. The student keeps authorship.
Designed with a neurodivergent user
This project was not designed around an imagined neurodivergent user.
I was one of the users.
As a neurodivergent student with CAS, I evaluated Bridge against a question that cannot be answered by a benchmark alone:
When the system is wrong, does it make me feel trapped, or does it help me recover?
That question changed the design. It led to six nonnegotiable rules:
- A complete sentence can never be required.
- Voice can be available, but it can never be the only path.
- The system must preserve the user's exact words.
- Uncertainty must be visible instead of hidden behind confident language.
- Bridge should ask one missing question instead of restarting the conversation.
- Nothing can be prepared or sent without explicit confirmation.
My lived experience shaped not only the visual design, but also the authority boundaries inside the code.
How I built it
Bridge is built with React 19, Next.js 16, TypeScript 5.9, Vite, vinext, and a Cloudflare deployment target. The public experience is statically rendered and served through a Cloudflare Worker.
The semantic engine is intentionally local, deterministic, and inspectable. It does not call a language model or external application API. This prevents nondeterministic phrasing, protects the public build from exposed credentials, and makes every interpretation reproducible.
1. An interpretable concept engine
Traditional chatbot intent systems often depend on exact phrases or a single large model prediction. Bridge uses a hybrid semantic ranking system.
First, it normalizes the input using Unicode NFKD normalization, accent removal, lowercase conversion, punctuation cleanup, and phrase normalization.
Next, it creates several independent representations of the message:
- A curated concept vector representing dimensions such as brightness, noise, crowding, health, overwhelm, human support, quiet, movement, and schoolwork.
- A 128 dimensional signed hash vector constructed from character bigrams and trigrams.
- A fuzzy token representation using Damerau Levenshtein distance, which can recover insertions, deletions, substitutions, and adjacent character transpositions.
- Explicit phrase coverage over supported aliases.
- Bounded contextual compatibility from the synthetic classroom state.
For an input $x$, candidate meaning $c$, and context $\kappa$, the primary ranking function is:
$$
S(c \mid x,\kappa)
0.50\,C(x,c) + 0.22\,G(x,c) + 0.18\,F(x,c) + 0.05\,P(x,c) + 0.05\,K(\kappa,c) $$
Here:
- $C$ is cosine similarity between concept vectors.
- $G$ is hashed character gram similarity.
- $F$ is fuzzy token similarity.
- $P$ is direct phrase coverage.
- $K$ is bounded contextual compatibility.
The weighting matters. In ordinary text interpretation, context contributes at most five percent of the score. It can resolve a supported ambiguity, such as whether "too bright" refers to the classroom lights or a laptop screen, but it cannot dominate the student's words.
2. Meaning is composed instead of guessed
Bridge decomposes a support request into three separate semantic slots:
$$ \text{Meaning} = \text{Issue} + \text{Source} + \text{Requested Support} $$
For example:
$$ \text{Too Bright} + \text{Classroom Lights} + \text{Quiet Room} $$
Each slot requires its own evidence.
This prevents an important failure mode. If a student says, "I feel sick," Bridge may identify a health concern, but it does not automatically decide that the student wants the nurse. It asks, "What would help?"
Context can reveal that the nurse or quiet room is available. Availability is not permission to choose it for the student.
The engine also contains explicit negation handling. "The noise is fine" must not become "It is too loud." "I love science" must not become "I need help with schoolwork."
When evidence is missing, Bridge returns a structured missing slot and asks one focused question.
3. Safe abstention is a real output
Most classifiers are rewarded for always producing an answer. Bridge is designed to refuse unsupported certainty.
The engine calculates a legibility score from recognized concept coverage and word like structure:
$$
L(x)
0.6\left(\frac{\text{known tokens}}{n}\right) + 0.4\left(\frac{\text{word like tokens}}{n}\right) $$
If input is extremely unclear, Bridge moves to broad context supported choices. If input is understandable but outside the supported domain, Bridge safely abstains instead of forcing it into the nearest category.
Messages such as "tell me a joke," "purple tomorrow," and "I love science" are tested to ensure they do not become invented support problems.
Unsupported input is not an exception. It is a first class product state.
4. Voice is treated as fallible
Generic speech recognition should not be described as a CAS decoder.
The submitted prototype uses the browser Web Speech API when available, but treats its transcript as editable input rather than ground truth. Recognition results are rebuilt from complete final and interim snapshots so repeated browser events cannot duplicate previously captured words.
If the student has already typed something, spoken input is merged with that draft instead of replacing it.
The voice interaction is half duplex. Starting recognition stops speech output. Starting speech output stops recognition. Monotonic turn identifiers invalidate stale callbacks so an older browser event cannot overwrite a newer interaction.
Each voice turn can produce exactly one spoken Bridge response. That response is also visible in text and can be stopped, replayed, or disabled.
Voice can never select an interpretation, confirm a meaning, or prepare a ticket.
If speech recognition fails, the typed and no words routes remain fully available. This is essential for CAS because an accessibility product cannot make ordinary speech recognition the gatekeeper to communication.
5. Consent is enforced by a state machine
Bridge uses a reducer driven state machine with six experience stages:
$$ \text{Compose} \rightarrow \text{Interpretation} \rightarrow \text{Need} \rightarrow \text{Review} \rightarrow \text{Sent} $$
A guided no words path connects to the same interpretation and confirmation model.
Invalid, stale, repeated, and premature actions fail closed as no operations. A ticket cannot be prepared outside the review stage.
The student's original words remain selected by default. A phrased message is stored separately and can only be selected intentionally.
After confirmation, Bridge freezes a structured local help desk payload containing:
- The exact message body.
- The original raw input.
- The selected message mode.
- The input source.
- The confirmed meaning.
- The context evidence used.
- The priority and destination.
- The timestamp and interaction count.
Authorship is not merely a design principle. It is represented directly in the data model.
6. Context with provenance
The prototype uses four clearly labeled synthetic signals:
- Fluorescent classroom lights are on.
- Maya is in Science in Room 214.
- The quiet room is available.
- Ms. Alvarez is on duty.
Every hypothesis preserves the exact context evidence that affected it.
The context system is hidden behind a typed SchoolContextProvider interface. A production server could replace the synthetic provider with an authenticated, user scoped Composio session that reads only an approved allowlist of school data. The same server boundary could deliver the final confirmed payload to Zendesk or another help desk.
That connection is not active in the public demo. No Composio key, student account, live Zendesk request, or external application API exists in the browser bundle.
7. Accessibility beyond inference
Bridge also includes:
- Keyboard navigation and visible focus states.
- Screen reader labels and polite live announcements.
- Reduced motion support.
- Large interaction targets.
- Spoken responses with stop and replay controls.
- Outgoing message read aloud with word highlighting.
- Original words selected by default.
- A complete no words communication path.
ASHA recognizes augmentative and alternative communication, including visual choices and speech generating tools, as an important support when speech alone is not sufficient for a person with CAS. Bridge is not speech therapy or a clinical AAC device, but its multimodal design follows the principle that communication should never depend on one channel alone.
Testing and technical execution
The current build passes TypeScript validation, completes a production static build, and passes all 50 automated tests across eight test files.
The tests cover:
- Severe misspellings and jumbled fragments.
- Concept composition and missing slot detection.
- Negation and false positive prevention.
- Safe abstention.
- Direct human requests.
- Urgent language routing.
- Request only fragments that must not invent a cause.
- Stale, repeated, and premature state actions.
- Voice transcript reconstruction.
- Spoken response overclaim prevention.
- Exact word preservation.
- Context provenance.
- Public bundle restrictions against credentials, application API calls, and persistent browser storage.
The objective was not only to build a path that succeeds. It was to test the ways an accessibility system can fail.
The central technical novelty
The novelty of Bridge is not simply typo correction, voice recognition, or intent classification.
It is inference under consent.
Most support systems optimize for the fastest route from message to category. Bridge optimizes for the safest route from uncertain expression to user confirmed meaning.
Its technical contribution is the separation of four things that chatbots often collapse:
$$ \text{Raw Expression} \neq \text{Predicted Meaning} \neq \text{Optional Phrasing} \neq \text{Confirmed Message} $$
Bridge keeps all four distinct.
Context can support an interpretation without becoming an instruction. A prediction can be useful without becoming authoritative. A clearer sentence can exist without replacing the original voice.
The system can be intelligent enough to help while remaining limited enough to listen.
Challenges I faced
The first challenge was emotional. Building Bridge required turning a deeply personal frustration into a system that other people could inspect. I had to describe the moments when communication technology makes me feel least understood and convert those moments into engineering requirements.
The second challenge was balancing assistance with authorship. A more aggressive engine could produce faster results. It could also confidently speak over the user. Designing abstention, missing slot questions, exact word preservation, and explicit confirmation required more work than producing one polished answer.
The third challenge was voice. Speech recognition is asynchronous, browser dependent, and particularly unreliable for the users who need flexibility most. I chose not to hide that limitation. Bridge treats speech as one optional signal and always preserves a recovery path.
The fourth challenge was making the integration story honest. It would have been easy to show a fake Zendesk success screen and imply that a real ticket was delivered. Instead, Bridge clearly labels its output as a local demo payload and exposes a technically credible server integration boundary for future deployment.
What I learned
I learned that accessibility is not measured only by how often a system is correct. It is measured by what happens when the system is wrong.
- Can the user reject it?
- Can they edit it?
- Can they keep their own words?
- Can they reach a person?
- Can they proceed without speech?
- Can they leave without the system claiming something they never said?
I also learned that uncertainty can be a feature. "I am not sure" is sometimes the most respectful and technically accurate response an AI system can provide.
Most importantly, I learned that the role of accessible AI is not to make a neurodivergent person appear more typical. Its role is to remove the unnecessary performance demanded by the interface.
What comes next
The next stage of Bridge would involve structured co design with more people who have CAS, families, educators, and speech language pathologists.
Future research would evaluate:
- Opt in speaker specific acoustic representations for personalized functional vocabulary.
- Visual symbol and gesture input alongside voice and text.
- Multilingual concept catalogs.
- Calibrated abstention across broader support domains.
- Secure, authenticated context connectors.
- Confirmed Zendesk and school support delivery.
- Metrics such as top candidate recall, false confidence rate, repair turns, correction rate, and time to confirmed meaning.
Any future speech personalization must be consensual, private, and evaluated with people who actually have CAS. Bridge should never diagnose CAS from a voice sample or claim to replace professional speech language support.
Why Bridge matters
I built Bridge because I know what it feels like to have meaning judged by delivery.
CAS has taught me that speech and thought are not the same thing. Fluency and intelligence are not the same thing. A pause is not an absence of ideas. An imperfect sentence is not an imperfect person.
Bridge is my attempt to make technology remember that.
The words were always there. The system just had to stop demanding them in one perfect form.
Built With
- composio
- octen
- openai-(codex)
- zendesk
Log in or sign up for Devpost to join the conversation.