It's stated here that "links" mode will be the default, but when I experiment with the example at https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/scroll-marker-group it looks like "tab" mode is the scroll-marker-group behavior that's shipped in Chromium today. Changing this will cause a difference in behavior for sites that already use scroll-marker-group without specifying the mode, e.g. sites will see the single tab stop on a scroll-marker-group become multiple tab stops. Is this compatibility risk something you've considered?
> Is this feature fully tested by > web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? > Yes > https://wpt.fyi/css/css-overflow/scroll-markers This looks like test coverage for the broader scroll-marker-group feature, but is there coverage for the new functionality being proposed here? The only of these tests with "mode", "link", or "tab" in the name are already passing in Chrome Stable. > Web developers: No signals It would be better if we could point to some evidence of developer interest. Who is asking for this feature? > TAG review status Not applicable Can you say why TAG review isn't applicable? > Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1161) > WebKit: No signal (https://github.com/WebKit/standards-positions/issues/447) I think it's reasonable to reuse the Gecko and WebKit signals for carousel, but it'd be nice to post an update to those threads mentioning that you intend to ship this additional behavior. Lastly, please request the other reviews in Chromestatus (Privacy, WP security, etc). Thanks, Dan From: [email protected] <[email protected]> On Behalf Of Chromestatus Sent: Wednesday, July 15, 2026 12:40 PM To: [email protected] Cc: [email protected] Subject: [blink-dev] Intent to Ship: CSS scroll-marker-group modes Contact emails [email protected]<mailto:[email protected]> Explainer https://gist.github.com/danielsakhapov/aa8e744701224994609aebb3e9e316e3 Specification https://drafts.csswg.org/css-overflow-5/#scroll-marker-modes Summary The scroll-marker-group property is enhaced to support modes: 1) 'links' - The generated ::scroll-marker-group operates in "links" mode, functioning like a navigation list. This is the default mode if omitted. 2) 'tabs' - The generated ::scroll-marker-group operates in "tabs" mode, functioning like a tablist. Each mode changes focus order and accessibility behavior of ::scroll-marker-group and ::scroll-markers, following WAI-ARIA patterns. More details: # The links mode (default) This mode is designed to mimic standard Navigation Landmarks combined with fragment anchors. ## Semantic roles The ::scroll-marker-group takes on the navigation role, and the ::scroll-marker elements take on the link role. This perfectly maps to the <nav> + <a> structural pattern. ## Keyboard navigation All ::scroll-marker elements are sequential tab stops, natively acting like a list of standard anchor links. ## Unaffected targets The originating elements do not get forced into any role, leaving the document's natural semantic structure intact. ## Activation focus management When a link marker is activated, it sets the sequential focus navigation starting point to the target element (the originating element), and focus is lost from the marker. This mimics the native behavior of clicking a standard internal <a href="#target"> link. # The tabs mode This mode is designed to natively replicate the Tabs Pattern and serves as the interactive foundation for the Tabbed Carousel Pattern. ## Semantic roles The ::scroll-marker-group is implicitly assigned the tablist role, ::scroll-marker elements act as tab roles, and their originating elements get the tabpanel role. This mirrors the required WAI-ARIA Tabs structure. ## Keyboard navigation (roving tabindex) It follows the complex keyboard interactions outlined in standard practices. Only the active ::scroll-marker acts as a tab stop. Users use arrow keys to navigate the focusgroup (switching between markers), preventing the "tab trap" of having to tab through 20 carousel dots. ## Focus scope management The marker acts as a focus navigation scope owner. Pressing Tab from the active marker moves focus directly into the active tabpanel content, matching the specification for tabbed interfaces. ## Tree pruning Content from inactive tabs is explicitly hidden from the accessibility tree. This mimics the expected behavior of aria-hidden="true" or inert on inactive tab panels, saving developers from manually scripting state changes. ## Activation focus When a marker is activated, focus is retained on the marker, which is exactly how standard tabs operate. Blink component Blink>CSS<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> Web Feature ID Missing feature Motivation No information provided Initial public proposal No information provided TAG review No information provided TAG review status Not applicable Goals for experimentation None Risks Interoperability and Compatibility No information provided Gecko: No signal (https://github.com/mozilla/standards-positions/issues/1161) WebKit: No signal (https://github.com/WebKit/standards-positions/issues/447) Web developers: No signals Other signals: https://github.com/w3c/css-aam/issues/18 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)? Yes Is this feature fully tested by web-platform-tests<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? Yes https://wpt.fyi/css/css-overflow/scroll-markers Flag name on about://flags No information provided Finch feature name No information provided Non-finch justification No information provided Rollout plan Will ship enabled for all users Requires code in //chrome? False Estimated milestones No milestones specified 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/5109685301673984?gate=6191471012216832 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]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a57e20c.854c7482.198413.02a4.GAE%40google.com<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a57e20c.854c7482.198413.02a4.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/DS0PR00MB252785759BCEC7A995D4EA66C5C32%40DS0PR00MB2527.namprd00.prod.outlook.com.
