Thanks for the background, and to Jeff Yassking for clarifying that the available() API allows feature detection. LGTM1
On Monday, May 11, 2026 at 1:22:39 PM UTC-7 [email protected] wrote: > A TAG review was also requested for the quality hint here: > https://github.com/w3ctag/design-reviews/issues/1189 This was resolved as > "satisfied with concerns". > > The `processLocally` option is part of the on-device speech recognition > feature which was approved and launched last year. > > Also, the PR adding the quality hint to the spec landed: > https://webaudio.github.io/web-speech-api/#speech-recognition-quality-values > > Let me know if anyone else has any questions or concerns! > > Thanks, > Evan > > On Mon, May 11, 2026 at 11:53 AM Reilly Grant <[email protected]> > wrote: > >> "processLocally" comes from the earlier iteration on this feature the TAG >> reviewed here: https://github.com/w3ctag/design-reviews/issues/1038 >> >> It looks like a separate TAG review wasn't requested for the recognition >> quality attributes being added here. >> Reilly Grant | Software Engineer | [email protected] | Google Chrome >> <https://www.google.com/chrome> >> >> >> On Mon, May 11, 2026 at 11:42 AM Alex Russell <[email protected]> >> wrote: >> >>> 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 >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2128a6d5-2fb2-48a6-a8e9-6739ee6ec28dn%40chromium.org?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/af248825-2f1f-4ef3-8c68-51243a2db22fn%40chromium.org.
