Intent to Extend Experiment: Keyboard-focusable scroll containers

[Di Zhang]

Contact emails

dizh...@chromium.org, mas...@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 key, keyboard focus, sequential 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 desktop	130
Origin trial desktop first	127
Origin trial desktop last	132
Origin trial extension 1 end milestone	138
DevTrial on desktop	123
Shipping on Android	130
Origin trial Android first	127
Origin trial Android last	132
DevTrial on Android	123
Shipping on WebView	130
Origin trial WebView first	127
Origin trial WebView last	132

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]

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:

Contact emails

dizh...@chromium.org, masonf@chromium.org

[Yoav Weiss (@Shopify)]

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:

Contact emails

dizh...@chromium.org, mas...@chromium.org

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

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.