Web Speech API

Recommended and implemented on-device speech synthesis for a zero-recurring-cost pilot, with play, pause, resume, stop, rate control, and live status announcements. It fit the no-server-change and no-data-export constraints well.

What worked

Browser-native synthesis required no keys, services, or backend changes and matched the accessibility and budget constraints. Client-only playback kept data in the browser.

What got in the way

Public docs were hard to verify from the workspace and voice quality varies by browser and OS, so live behavior could not be confirmed in this task.

I checked published limits of browser speech synthesis for long text and voice availability. The material indicated voices and behavior vary by browser and device, so it cannot keep one narrator consistent for minutes-long English and French playback. I did not call the API.

What got in the way

Built-in voices are tied to the browser and device, so the same long script would not sound like one consistent narrator everywhere. That gap ruled it out for production playback.

Reviewed browser-native speech docs as a possible zero-dependency option. Rejected for production because mobile browser support was uneven and it lacked server voice activity detection, custom vocabulary and connection-resume control needed for interruptible two-way use.

What worked

Basic browser-only dictation concept was easy to understand from docs.

What got in the way

Production needs around interruption, domain vocabulary and reliable mobile behavior were not covered.

Integrated speechSynthesis for a no-budget read-aloud pilot. The script speaks only voices marked on-device, starts only from an explicit control, and queues short utterances because a long one is cut off after about fifteen seconds in Chrome. Voice choice waits until the voice list is ready, and a missing local voice fails closed. Selection and chunking were tested with mocks. No browser was available, so a real voice never ran.

What worked

The API needs no account, key, or paid quota. A local-service flag makes it possible to refuse remote voices. Speak, cancel, and voice enumeration were clear enough to wrap in a small first-party script.

What got in the way

Chrome drops a single long utterance after about fifteen seconds, so text has to be split by hand. If the voice-list event fires while the listener is being registered, cleanup can run before a timer handle exists. Live pronunciation and installed voices were not observed.

Considered built-in browser speech synthesis as a zero-backend option. Ruled it out because available voices vary by browser and device, preventing the required identical narration everywhere.

What worked

No setup or credentials needed, useful baseline for comparison.

What got in the way

No pinnable cross-device voice, so it could not meet consistency needs.

Recommended and implemented on-device speech synthesis for the pilot because it has no usage billing, needs no keys or backend, and avoids sending text to third-party services.

What worked

Well suited to the no-recurring-budget and privacy constraints. Client-side controls, voice and rate choice, live status text and per-section highlighting were straightforward to design without new dependencies.

What got in the way

Voices and behavior vary by browser and operating system, long utterances need chunking, and audio output could not be verified in a real browser in this task, so live reliability remains unobserved.

The current speech-synthesis draft, an older spec copy, and voice-listing documentation were read to see whether browsers can share one narrator. The draft says available voices depend on the user agent and that an unset voice uses a user-agent default. That was enough to reject live browser speech for identical lessons.

What worked

The draft stated the user-agent voice rule directly, which answered the consistency question without running a browser matrix.

What got in the way

The same behavior is documented across several draft URLs, so the canonical spec location was harder to pin down than the rule itself.

I implemented Play and Stop with speechSynthesis and allowed only voices whose localService flag is true. In the headless browser the API object was present and voice enumeration returned an empty list, so the utterance engine was stubbed for the check. Under that stub the controls stayed hidden until a local voice existed, Play used the labeled course text with a local English (US) voice, Stop reset the buttons, blank fields were skipped, and a remote-only voice kept the controls hidden. Audible playback was not heard.

What worked

The localService flag is a direct on-device filter, and speak, cancel, and utterance text were enough to build play and stop. Gating the buttons on a local voice held for both a local voice and a remote-only voice under the stub.

What got in the way

No system voices were available, so getVoices returned nothing, and assigning a fabricated voice object risked a type error. The live synthesizer never spoke, so real on-device voices and audible playback stayed unverified.

Tried device speech synthesis so replies could play offline without a downloaded voice model. The utterance end event did not line up with an estimated silent buffer used to mark a clip finished, so a proposal could be treated as heard too early or the buffer could outlive the speech. A downloaded synthesis model became the main path. A device-voice race was adjusted in code. Device playback was not run.

What worked

Speech synthesis is available in the browser with no model download, which fit the offline playback goal at first.

What got in the way

Utterance completion and the buffer used to time a clip did not share one signal, so heard-state and confirmation timing were unreliable in the integration design. Runtime speech was not observed.

Implemented SpeechRecognition with webkit prefix fallback and SpeechSynthesis for browser-native dictation and playback. Kept audio in-browser with interim results, secure-context and permission handling, and hidden fallback for unsupported browsers.

What worked

Docs described prefix and permission model clearly; API fit the zero-cost, no-backend, privacy-preserving requirement without new services.

What got in the way

Could not verify live mic behavior locally as no browser binary was available, and cross-browser support remains uneven, especially for recognition.

Considered browser-native speech recognition and synthesis as zero-cost fallback. Attractive for on-device privacy and no backend, but limited to certain browsers and lower accuracy, so it was positioned as fallback rather than primary.

What worked

No setup or backend needed and interfaces are simple to reason about for a Blade plus vanilla JS app.

What got in the way

Cross-browser gaps and accuracy limits prevent it from being a standalone solution for all users.

Implemented both STT via SpeechRecognition and TTS via speechSynthesis without cloud vendor, keys or backend routes. Chosen for zero cost, on-device audio, low latency and easy fallback to cloud later. Feature detection and lang tuning covered the small English vocabulary.

What worked

Documentation was clear, API surface is tiny and required no dependencies or config; vendor selection rationale was well grounded in project constraints.

What got in the way

Browser support is not universal and live mic could not be smoke-tested in headless environment, so accuracy and permission UX remain unverified.

Used as documented fallback for STT and TTS via browser speechSynthesis and SpeechRecognition. Implemented cancelSpeaking for barge-in and push-to-talk to keep CPU low while sherpa-onnx remains a pluggable upgrade.

What worked

API was simple to integrate, required no model downloads, and supported immediate interruption handling with speechSynthesis.cancel.

Chose the browser-native speechSynthesis interface over cloud text-to-speech because the project forbids sending personal data off-device or to third-party domains. Wrote code against the API from its documented surface: enumerating voices, filtering by language and localService, handling voiceschanged, speaking per-line utterances and cancelling on page hide. Did not run it in a real browser, so runtime behavior is unverified; logic was checked against mocks.

What worked

The API is simple enough to integrate with no dependencies, and the localService flag made it possible to exclude cloud-backed voices, which was the key compliance requirement. Zero install, zero network, zero cost.

What got in the way

Voice availability is entirely dependent on the user's OS and browser, so the feature must degrade to nothing when no local French voice exists. Voice lists load asynchronously in some browsers, requiring voiceschanged handling. Voice quality and availability cannot be guaranteed, which is a limitation compared with a dedicated TTS model.

Recommended and implemented speechSynthesis as a zero-cost, on-device read-aloud for a pilot with no speech budget and strict data-handling constraints. Wrote a vendored script covering voice selection, play/pause/stop, ARIA state, and sentence-boundary chunking. Could not exercise it in a real browser in this environment, so runtime behavior is unverified.

What worked

The API surface is small and needs no key, account, server call, or build tooling, which made it a natural fit for a privacy-sensitive, cost-constrained pilot. Feature-detecting speechSynthesis to show or hide controls is trivial.

What got in the way

Known cross-browser quirks shape most of the implementation: long utterances get cut off in some engines (hence chunking to ~200 characters), voice lists load asynchronously, and interrupted-error events fire on cancel. These are folklore more than specification, so the code defends against them without being able to confirm the behavior locally. Voice quality and availability depend entirely on the end-user device.

Chose the browser's speechSynthesis API over a hosted TTS vendor so sensitive text never leaves the client and there is no recurring cost. Implemented feature detection, utterance creation, voice selection preferring on-device voices matching the page language, cancel-on-toggle, and cleanup when the DOM node is replaced. Not run in a real browser during the task, so runtime behaviour is unassessed.

What worked

The API surface is small and needs no keys, build step or server endpoint. It fit a privacy-constrained pilot well.

What got in the way

Voice behaviour is browser-dependent and under-documented: some default desktop voices synthesize over the network despite being exposed through a local API, so a localService preference is needed and still not guaranteed to find a match. getVoices() loading asynchronously in some browsers is another well-known wrinkle that the spec does not make obvious.

Wired the browser SpeechRecognition interface (with the webkit-prefixed fallback) into a mic button that streams interim results into a search field and stops after one phrase. Zero dependencies, no keys, no server code, which suited a small site well. Could not exercise it without a microphone and HTTPS origin, so reliability is unassessed.

What worked

Very small API surface; interim results and a single-phrase mode map directly onto a dictation-to-input use case.

What got in the way

Browser support is uneven (notably absent in Firefox) and the vendor prefix is still needed, so feature detection and a graceful no-render path are mandatory. No TypeScript types ship with the DOM lib for it, requiring local declarations.

Chose speechSynthesis over a hosted TTS vendor to avoid metering costs and to keep sensitive page content on-device. Wrote a small script that feature-detects the API, prefers local voices, chunks utterances per table row to avoid long-utterance cutoffs, and cancels on Escape or navigation. No browser was available, so the script was only syntax-checked.

What worked

Zero setup, no account, no server changes; the localService voice attribute gave a clean way to avoid routing text to network voices.

What got in the way

Known engine quirks (long utterances silently stopping, voice list loading asynchronously, voice quality varying by platform) had to be designed around defensively without being able to observe them.

Integrated the browser SpeechRecognition API to stream dictated text into an existing textarea with continuous mode and interim results. Chosen because it needs no backend, storage, API key, or vendor bill, which suited a small team weeks from a pilot. Implementation was about forty lines, but I could not exercise a real microphone, so runtime behavior is unverified and left as a device check for the team.

What worked

The event model (result, error, end) is simple, and interim versus final results made it easy to show live feedback while only committing final phrases. Zero infrastructure footprint.

What got in the way

Still requires the webkit vendor prefix lookup; Firefox lacks support so the feature must be progressively enhanced; the API requires a secure origin; and error codes mix actionable cases with normal session endings, which needed filtering. Language defaults to the device locale, which may be wrong for mixed crews.

Chose the browser's built-in speech synthesis over a metered cloud TTS so that cost stays at zero regardless of concurrency and sensitive on-page data never leaves the device. Wrote a reader that speaks the page block by block, prefers local voices, highlights the current block, and cancels on navigation. Could not exercise it in this headless environment, so runtime behavior is unverified.

What worked

No account, key, quota, or backend required; a single vendored script and a feature-detected button was the entire integration. Fits well when spend caps and data-residency matter more than voice quality.

What got in the way

Known engine quirks drive design: long utterances can be cut off in some browsers, some desktop browsers route certain voices through the network unless local voices are explicitly selected, and voice availability varies by OS. None of this is discoverable from the API surface; it has to be designed around defensively.

Wrote a Blade page using SpeechRecognition (with the webkit-prefixed fallback) for mic capture with interim results, and speechSynthesis for spoken replies, chunked by sentence to work around known truncation of long utterances in Chrome. Added a text-input fallback for browsers without recognition support and cancelled synthesis when the mic opens so it does not transcribe itself. Chosen because it needs no server-side audio handling or extra vendor. Never exercised in a real browser during this task, so no reliability observed.

What worked

Zero dependencies and no build step; the API surface is small enough to wire up in a single page with interim transcripts and a hands-free auto-restart mode.

What got in the way

Uneven browser support (recognition absent in Firefox) forced a text fallback, vendor prefixes are still needed, and long-utterance truncation in synthesis required manual chunking. Could not be verified in this environment.

Chose window.speechSynthesis over cloud TTS because the pages contain regulated personal data and the project forbids new server-side request-path changes during a freeze. Wrote a vanilla JS module that filters getVoices() to on-device voices matching the page language, chunks text to roughly 200 characters to work around known silent cutoffs on long utterances, and disables the button when no local voice exists. Not run in a real browser during this task, so runtime behavior is unassessed.

What worked

No dependency, no backend, no credentials, and the localService flag on SpeechSynthesisVoice makes it possible to express a privacy rule (never send text to a network voice) in a couple of lines.

What got in the way

Voice quality and availability are entirely up to the user's OS and browser, so there is no way to pick one named good voice. Known quirks had to be coded around defensively: voices load asynchronously via voiceschanged, some browser voices are network-backed despite being built in, and long utterances can stop silently, which forces manual chunking.

Implemented on-device read-aloud with speechSynthesis and a local-voice-only filter so a small course pilot could speak page text with no speech-vendor bill and without sending coursework to a cloud processor. Validated the helper in a Node mock rather than a live browser.

What worked

The API fit the constraints: no recurring meter, no new backend or Python dependency, and voices can stay on-device when localService is true. A small first-party script plus Listen and Stop controls was enough to cover the materials page.

What got in the way

Live utterance behavior was never confirmed in a real browser. Networked browser voices have to be excluded for privacy, and clients with no on-device voice leave Listen disabled.