Thanks for the clarification. However pushing the screen reader announcement model to a follow-up while moving forward with prototyping a core feature like multi-range selection is deeply concerning. Clipboard and selection operations are not secondary UI cosmetics; they are core, daily architectural workflows for assistive technology users.
Treating non-visual users with a focused range only approach during the prototype stage introduces two critical flaws that come to mind initially: 1. A screen reader user will expand their selection but the AT will only report the single focused range. When they hit Ctrl+C, the clipboard will contain disjointed data that the user never heard or verified. This is a direct data integrity and user frustration risk. 2. Given Chromium's existing architectural challenges regarding accessibility, prototyping new features without a fully designed AX communication layer risks introducing significant technical debt. History shows that when accessibility implementations are deferred as secondary follow-ups, they can unfortunately face extensive delays before getting resolved. Baking the AX layer into the initial foundation ensures a more sustainable architecture and prevents future refactoring. I strongly urge the owners to define the screen reader interaction model in parallel with the current prototype, rather than after it. 24 Haziran 2026 Çarşamba tarihinde saat 12:51:53 UTC+3 itibarıyla Sambamurthy Bandaru şunları yazdı: > @Emre, > > The current prototype covers the JS API, input gestures (Ctrl/Cmd+click, > keyboard extend), clipboard, and painting. A fully specified screen-reader > announcement model is still a follow-up. Until it lands, a multi-range > selection is conveyed to AT as the focused range only. > > > > > On Tuesday, June 23, 2026 at 9:28:38 PM UTC+5:30 Emre TEKE wrote: > >> Hello, >> >> I am writing this as an independent Chromium contributor. >> >> I have reviewed the specification and noticed that it primarily focuses >> on mouse events. While the documentation mentions accessibility in passing, >> I could not find specific examples regarding how a screen reader user would >> interact with multi-range selection. >> >> I would appreciate it if there is any relevant documentation or a >> specific prototype that demonstrates this behavior. >> >> Although I frequently use VS Code and other cited examples, I am not >> familiar with how multi-range selection is handled via screen readers. >> >> I apologize if this inquiry is outside the typical scope of this group; >> however, this remained unclear to me after reading the spec and I felt this >> would be the best place to ask for clarification. >> >> 17 Haziran 2026 Çarşamba tarihinde saat 07:07:28 UTC+3 itibarıyla >> Chromestatus şunları yazdı: >> >>> *Contact emails* >>> [email protected] >>> >>> *Explainer* >>> >>> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Editing/multi-range-selection-explainer.md >>> >>> *Specification* >>> https://github.com/w3c/selection-api/pull/359 >>> >>> *Summary* >>> Enables Selection API to hold and manipulate multiple disjoint ranges >>> within a single document. Users can create discontinuous text selections >>> via input devices or JavaScript APIs, and clipboard copy includes all >>> selected ranges joined with newline delimiters. >>> >>> *Blink component* >>> Blink>Editing>Selection >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EEditing%3ESelection%22> >>> >>> *Web Feature ID* >>> Missing feature >>> >>> *Motivation* >>> Desktop applications like Microsoft Word and LibreOffice Writer support >>> Ctrl+Click (Cmd+Click on macOS) to build non-contiguous selections. On the >>> web, this interaction is blocked by spec-mandated single-range behavior in >>> current Chromium, where Ctrl+Click replaces the existing selection. The gap >>> is particularly noticeable for: Users switching between desktop editors and >>> browsers who expect consistent Ctrl+Click behavior Power users copying >>> non-adjacent table cells Web-based code editors that want native >>> multi-cursor selection without custom overlays The Selection API exposes a >>> Selection object with methods like addRange(), removeRange(), >>> getRangeAt(index), and the rangeCount attribute, all originally designed >>> for collections of disjoint Range objects. In 2011, the spec was narrowed >>> to single-range semantics: addRange() is ignored when a range already >>> exists, and rangeCount is constrained to 0 or 1. Chromium follows this >>> restriction today, while Firefox has long supported multi-range behavior. >>> Issue https://github.com/w3c/selection-api/issues/358 had been >>> discussed in the W3C Web Editing Working Group to restore multi-range >>> semantics and align implementations across browsers with the API’s original >>> design intent. >>> >>> *Initial public proposal* >>> https://github.com/WICG/proposals/issues/291 >>> >>> *Search tags* >>> range <http:///features#tags:range>, multi-range >>> <http:///features#tags:multi-range>, selection >>> <http:///features#tags:selection> >>> >>> *Goals for experimentation* >>> None >>> >>> *Requires code in //chrome?* >>> False >>> >>> *Tracking bug* >>> https://issues.chromium.org/issues/504686717 >>> >>> *Estimated milestones* >>> >>> No milestones specified >>> >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5095241565732864?gate=5095962528841728 >>> >>> 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/5f5a9373-c518-4f53-93cc-fc66a21dfec1n%40chromium.org.
