Intent to Ship: Web Speech API: Unspoken Punctuation

[Chromestatus]

Contact emails

ev...@google.com

Explainer

https://github.com/WebAudio/web-speech-api/blob/main/explainers/unspoken-punctuation.md

Specification

https://webaudio.github.io/web-speech-api

Summary

Adds the unspokenPunctuation boolean attribute to the SpeechRecognition interface of the Web Speech API. When enabled (true), this attribute directs the speech recognition engine to automatically infer and insert punctuation marks (such as periods, commas, and question marks) based on the user's natural pauses, grammatical structure, and prosody, without requiring explicit spoken punctuation commands.

Blink component

Blink>Speech

Web Feature ID

speech-recognition

Motivation

Currently, developers building voice-enabled web applications—such as casual dictation tools, automated transcription services, or conversational assistants—receive raw, unpunctuated text streams from the Web Speech API. To make this text readable and polished, developers are often forced to implement and maintain complex downstream NLP models to infer basic formatting. Additionally, from an end-user perspective, having to explicitly dictate punctuation (e.g., stopping to say "comma" or "period") disrupts the natural flow of continuous speech and significantly increases cognitive load. Introducing the unspokenPunctuation attribute solves this by moving automatic, prosody-aware punctuation directly into the browser's speech recognition engine. This provides an intuitive, conversational voice typing experience for users out-of-the-box, while dramatically lowering the barrier to entry for developers building voice-driven web apps.

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

No information provided

Gecko: Positive (https://github.com/WebAudio/web-speech-api/issues/187#issuecomment-4479796822)

WebKit: No signal

Web developers: No signals

Other signals:

Ergonomics

N/A

Activation

N/A

Security

N/A

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

N/A, Not supported on Android

Debuggability

None required.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No
On-device Web Speech is only supported on Mac, Windows, and Linux.

Is this feature fully tested by web-platform-tests?

Yes

Flag name on about://flags

No information provided

Finch feature name

WebSpeechUnspokenPunctuation

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

True

Tracking bug

https://bugs.chromium.org/b/514764702

Measurement

N/A

Adoption expectation

Feature is used by specific partner (Google Meet) to provide functionality within 12 months of launch in Chrome.

Estimated milestones

Shipping on desktop	151
DevTrial on desktop	150

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/WebAudio/web-speech-api/pull/188/changes#diff-5e793325cd2bfc452e268a4aa2f02b4024dd9584bd1db3c2595f61f1ecf7b985

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4785284026859520?gate=4835184634626048

This intent message was generated by Chrome Platform Status.

[Alex Russell]

This looks really useful; were any alternative designs considered? Can they be documented in the Explainer (per our usual format)?

Best,

Alex

[Evan Liu]

Thanks for the feedback, Alex! I created a PR adding a section for "alternatives considered" to the Explainer: https://github.com/WebAudio/web-speech-api/pull/189/changes/cb93e856d59e3045c08937dca5e7d14f8aab0c44

Thanks,

Evan

[Alex Russell]

Thanks, that's helpful Evan. Given that we're out ahead on this one, are there engaged developers asking for it? I ask because there aren't any developer signals listed and we tend to view things with developer support as more likely to be worth the risk.

Best,

Alex

[Yoav Weiss (@Shopify)]

Can you file standard positions for both Mozilla and WebKit? 

Web developers: No signals

Any signals for developers?

[Evan Liu]

I've filed standard positions for Mozilla and WebKit. Mozilla has expressed support for this feature in the Github issue, but I don't think anyone at Apple is actively working on the Web Speech API at the moment.  Regarding developer signals, Google Meet is one site that has requested this functionality because it is critical for their use case.

[Alex Russell]

LGTM1

[Dan Clark]

LGTM2

[Rick Byers]

LGTM3

Regarding the WPT coverage it's this test, right? Is there a reason this can only be in wpt_internal instead of upstream wpt? Is there work tracking doing what it would take to get upstream? This is non-blocking for now since Chromium is the only impl, but if Gecko is going to be implementing at some point then we really need to do the work to get our full conformance test coverage upstream in WPT to make their lives easier. 

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b2db942d-cf9d-4c69-9b3e-aeaeb3a0d375n%40chromium.org.

[Evan Liu]

Is there a reason this can only be in wpt_internal instead of upstream wpt? 

According to this CL, the tests were originally moved to wpt_internal because they "need to load JS modules to continue using Mojo JS bindings. JS modules cannot be loaded from file:// URLs, so these must become HTTP tests." The speech tests rely on Chromium's internal Mojo bindings to mock the backend rather than a standardized testdriver.js API.