Hey Evan, It's surprising this didn't go through TAG review; if it had, I would expect feedback of the sort that the naming is odd. E.g. `processLocally: true` vs. `preferLocalProcessing: true` or similar. Or is the idea that it's a hard constraint? And if so, is there an ability to feature detect without bringing up the whole stack to find out?
Best, Alex On Wednesday, May 6, 2026 at 10:47:53 AM UTC-7 [email protected] wrote: > Thanks for the quick response, Rick! > > Do we know of any website who wants to use this API? In general we don't >> ship APIs that we don't have known customers for. > > Google Meet requires this feature to ensure that the on-device model used > by the Web Speech API meets its strict quality requirements. > > It looks like this is in this PR >> <https://github.com/WebAudio/web-speech-api/pull/186>, right? Is there >> any reason we shouldn't wait for the PR to land before shipping? > > Meet wants to use this feature in M150, but hopefully the PR will land > before then anyway! > > Why not? > > Android & ChromeOS currently do not support on-device Web Speech, so this > quality hint won't be available on those platforms. As for the lack of WPT > coverage, the testing infrastructure currently lacks a standardized way to > mock the hardware-dependent capabilities and subjective behaviors of > different on-device machine learning models. > > Thanks, > Evan > > On Wed, May 6, 2026 at 8:02 AM Rick Byers <[email protected]> wrote: > >> >> >> On Tue, May 5, 2026 at 6:48 PM Chromestatus < >> [email protected]> wrote: >> >>> *Contact emails* >>> [email protected] >>> >>> *Explainer* >>> >>> https://github.com/WebAudio/web-speech-api/blob/main/explainers/quality-levels.md >>> >>> *Specification* >>> https://webaudio.github.io/web-speech-api >> >> >> It looks like this is in this PR >> <https://github.com/WebAudio/web-speech-api/pull/186>, right? Is there >> any reason we shouldn't wait for the PR to land before shipping? >> >> *Summary* >>> Extends the SpeechRecognition interface by adding a quality property to >>> SpeechRecognitionOptions. This allows developers to specify the semantic >>> capability required for on-device recognition (via processLocally: true). >>> The proposed quality enum supports three levels—'command', 'dictation', and >>> 'conversation'—mapping to increasing task complexity and hardware >>> requirements. This enables developers to determine if the local device can >>> handle high-stakes use cases (like meeting transcription) or if they should >>> fallback to cloud services, solving the current "black box" issue of >>> on-device model capabilities. >>> >>> *Blink component* >>> Blink>Speech >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ESpeech%22> >>> >>> *Web Feature ID* >>> speech-recognition <https://webstatus.dev/features/speech-recognition> >>> >>> *Motivation* >>> While the introduction of processLocally: true was a significant step >>> for privacy and latency, it currently treats all on-device models as >>> functionally equivalent. In reality, on-device capabilities are highly >>> fragmented: a lightweight model optimized for simple voice commands (e.g., >>> "turn on the lights") is often insufficient for high-stakes use cases like >>> video conferencing transcription or accessibility captioning, which require >>> handling continuous speech, multiple speakers, and background noise. >>> Because developers currently have no way to verify the semantic capability >>> of the local model, they must blindly trust the device or default to >>> Cloud-based recognition to guarantee a minimum user experience. This lack >>> of transparency forces developers to bypass on-device capabilities for >>> high-end use cases, effectively negating the privacy and bandwidth benefits >>> of the API. There is a critical need for a mechanism that allows >>> applications to define their required "floor" of utility (e.g., >>> conversation-grade accuracy) to confidently utilize local processing. >>> >>> *Initial public proposal* >>> https://github.com/WebAudio/web-speech-api/issues/182 >>> >>> *TAG review* >>> *No information provided* >>> >>> *TAG review status* >>> Issues addressed >>> >>> *Goals for experimentation* >>> None >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> *No information provided* >>> >>> *Gecko*: Positive ( >>> https://github.com/mozilla/standards-positions/issues/1375) >>> Neutral/positive, >>> Firefox is launching on-device Web Speech using a single LLM model, so they >>> won't make use of this proposed quality hint but they don't have strong >>> objections against adding it. >>> >>> *WebKit*: No signal ( >>> https://github.com/WebKit/standards-positions/issues/634) N/A, Apple >>> doesn't have anyone actively working on the Web Speech API on the moment. >>> >>> *Web developers*: No signals >>> >> >> Do we know of any website who wants to use this API? In general we don't >> ship APIs that we don't have known customers for. >> >> >>> >>> *Other signals*: >>> >>> *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? >>> *No information provided* >>> >>> >>> *Debuggability* >>> *No information provided* >>> >>> *Will this feature be supported on all six Blink platforms (Windows, >>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>> No >>> >>> *Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> No >> >> >> Why not? >> >> >>> *Flag name on about://flags* >>> *No information provided* >>> >>> *Finch feature name* >>> OnDeviceWebSpeechQuality >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> True >>> >>> *Tracking bug* >>> https://g-issues.chromium.org/issues/476168420 >>> >>> *Estimated milestones* >>> Shipping 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). >>> *No information provided* >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5136859632107520?gate=6594055733641216 >>> >>> *Links to previous Intent discussions* >>> Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69694ed0.050a0220.f8796.0337.GAE%40google.com >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com>. >>> >>> -- >>> 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 [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69fa73a1.050a0220.e03d3.00f0.GAE%40google.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69fa73a1.050a0220.e03d3.00f0.GAE%40google.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2128a6d5-2fb2-48a6-a8e9-6739ee6ec28dn%40chromium.org.
