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/CAOVsCZ%3Dx%3DfwShxALoyJCsqpTUS%3De9GwcPykR3wBmmZbaCvsVag%40mail.gmail.com.
