Intent to Prototype: Multi-Range Selection

[Chromestatus]

Contact emails

sambamurt...@microsoft.com

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

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, multi-range, 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.

[Emre TEKE]

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ı:

[Sambamurthy Bandaru]

@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.

[Emre TEKE]

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ı: