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/9dd1dd0b-dbcb-455f-84bd-d68f3b93c421n%40chromium.org.
