LGTM3 /Daniel
On 2026-05-13 17:15, Vladimir Levin wrote:
LGTM2 On Wednesday, May 13, 2026 at 11:12:49 AM UTC-4 Alex Russell wrote: 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 <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 <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 <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] <mailto:[email protected]>> wrote: *Contact emails* [email protected] *Explainer* https://github.com/WebAudio/web-speech-api/blob/main/explainers/quality-levels.md <https://github.com/WebAudio/web-speech-api/blob/main/explainers/quality-levels.md> *Specification* https://webaudio.github.io/web-speech-api <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 <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 <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 <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 <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 <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 <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 aresubscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[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 subscribedto the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[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/ca02e82d-3111-4a2e-b648-270d419ded7fn%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca02e82d-3111-4a2e-b648-270d419ded7fn%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/6e8ff292-4628-494c-b553-bbc859debd57%40gmail.com.
