Intent to Extend Experiment: Keyboard-focusable scroll containers

135 views
Skip to first unread message

Di Zhang

unread,
Oct 29, 2024, 12:45:45 PMOct 29
to blink-dev

Contact emails

dizh...@chromium.orgmas...@chromium.org

Explainer

None

Specification

https://html.spec.whatwg.org/multipage/interaction.html#attr-tabindex

Design docs


https://drafts.csswg.org/css-overflow-3/#scroll-container
https://html.spec.whatwg.org/multipage/interaction.html#focusable-area
https://html.spec.whatwg.org/multipage/interaction.html#dom-tabindex

Summary

Improves accessibility by making scroll containers focusable using sequential focus navigation. Today, the tab key doesn't focus scrollers unless tabIndex is explicitly set to 0 or more. By making scrollers focusable by default, users who can't (or don't want to) use a mouse will be able to focus clipped content using a keyboard's tab and arrow keys. This behavior is enabled only if the scroller does not contain any keyboard focusable children. This logic is necessary so we don't cause regressions for existing focusable elements that might exist within a scroller like a <textarea>. Note: The previous rollout of this feature (started in Chrome 127) was stopped due to web compatibility issues, which should be fixed in the current implementation shipping in 130.



Blink component

Blink>HTML>Focus

Search tags

tab keykeyboard focussequential navigation

TAG review



TAG review status

Not applicable

Chromium Trial Name

KeyboardFocusableScrollersOptOut

Origin Trial documentation link

https://developer.chrome.com/blog/keyboard-focusable-scrollers

WebFeature UseCounter name

kNotApplicable

Risks



Interoperability and Compatibility

This is a change in behavior, but already matches what Firefox is doing (have scroller be focusable by default). Low compatibility risk since this default behavior is only enabled if the scroller doesn't have any focusable children.



Gecko: Shipped/Shipping Chrome behavior is slightly different since we are checking if any scroller child is focusable. This is to avoid regression on existing focus sequences.

WebKit: No signal (https://bugs.webkit.org/show_bug.cgi?id=190870)

Web developers: Positive (https://twitter.com/simevidas/status/1444033718742667270)

Other signals:

Ergonomics

There are no other platform APIs this feature will be used in tandem with. It will not be hard for Chrome to maintain good performance.



Activation

It will not be challenging for developers to take advantage of this feature immediately.



Security

There are no security risks, this is a change for keyboard focusing behavior.



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?

This is not high risk for WebView.



Goals for experimentation



Reason this experiment is being extended

Request to extend by another 6 milestones, from M132 to M138 We had to push our release plan from 127 to 130 to fix specific cases, per user requests [1]. As such, users only had 3 milestones to use the Origin Trial and adjust their sites to the new KeyboardFocusableScrollers behavior. Since this feature is changing a user noticeable behavior, we believe it would be safer to extend ahead. We already have a few comments mentioning depending on the Deprecation Trial: https://issues.chromium.org/issues/375425838#comment1 https://issues.chromium.org/issues/342705690#comment39 [1] https://issues.chromium.org/issues/361072782



Ongoing technical constraints

None



Debuggability

This is a change to focus navigation and DevTools does not offer debugging support for this behavior.



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?

No

Flag name on chrome://flags

KeyboardFocusableScrollers

Finch feature name

KeyboardFocusableScrollers

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1040141

Availability expectation

Firefox already implemented (a variant of this). If we succeed and don't break websites, Safari is more likely to follow suit.

Adoption expectation

This is a default behavior change and websites don't need to make changes.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

This feature does not depend on any APIs outside the chromium open source repository.

Estimated milestones

Shipping on desktop130
Origin trial desktop first127
Origin trial desktop last132
Origin trial extension 1 end milestone138
DevTrial on desktop123
Shipping on Android130
Origin trial Android first127
Origin trial Android last132
DevTrial on Android123
Shipping on WebView130
Origin trial WebView first127
Origin trial WebView last132


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

This change is not specced yet. If this succeed, we will try to get it specced.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5231964663578624?gate=4709973026930688

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/g/blink-dev/c/2qwzMaEGWTk/m/X5MILw3BAQAJ
Intent to Ship: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8dpmu3Dbykg%2BZ6e-Ka4r0r8kAiHAYmhU0WpGkEE%2B7Wzw%40mail.gmail.com


This intent message was generated by Chrome Platform Status.

Di Zhang

unread,
Oct 29, 2024, 5:31:27 PMOct 29
to blink-dev, Di Zhang
I noticed the above template drafted email makes it sound like I am talking about the feature and not the opt-out (deprecation) origin trial. I want to clarify this is a request to extend the Deprecation Origin Trial KeyboardFocusableScrollersOptOut only, which is currently expiring in M132. Thank you.

On Tuesday, October 29, 2024 at 9:45:45 AM UTC-7 Di Zhang wrote:

Yoav Weiss (@Shopify)

unread,
Oct 30, 2024, 6:30:17 AMOct 30
to Di Zhang, blink-dev
Just to see I understand the situation - while the deprecation trial started in M127, issues with the path we want developers to take only shipped in 130?

On Tue, Oct 29, 2024 at 10:31 PM Di Zhang <dizh...@chromium.org> wrote:
I noticed the above template drafted email makes it sound like I am talking about the feature and not the opt-out (deprecation) origin trial. I want to clarify this is a request to extend the Deprecation Origin Trial KeyboardFocusableScrollersOptOut only, which is currently expiring in M132. Thank you.

On Tuesday, October 29, 2024 at 9:45:45 AM UTC-7 Di Zhang wrote:

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/36e12cea-fb34-47aa-9642-ce8e0db33f57n%40chromium.org.

Yoav Weiss (@Shopify)

unread,
Oct 30, 2024, 11:28:04 AMOct 30
to Di Zhang, blink-dev
LGTM to extend the deprecation trial till M138 inclusive.

The process requires "significant progress", and I believe shipping the bug fixes in M130 qualifies as such.

On Wed, Oct 30, 2024 at 11:29 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:
Just to see I understand the situation - while the deprecation trial started in M127, issues with the path we want developers to take only shipped in 130?

Chris answered my questions here, so all good.
Reply all
Reply to author
Forward
0 new messages