Intent to Ship: Keyboard-focusable scroll containers

282 views
Skip to first unread message

Di Zhang

unread,
Apr 27, 2023, 5:29:07 PM4/27/23
to blink-dev

Contact emails

hu...@chromium.orgxiaoc...@chromium.orgdizh...@chromium.org

Explainer

None

Specification

None

Design docs

None

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



Blink component

Blink>HTML>Focus

Search tags

tab keykeyboard focussequential navigation

TAG review

None

TAG review status

Not applicable

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.



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, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name

KeyboardFocusableScrollers

Requires code in //chrome?

False

Tracking bug

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

Availability expectation

Firefox already implements (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 desktop114
Shipping on Android114
Shipping on WebView114


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

Links to previous Intent discussions

https://groups.google.com/a/chromium.org/g/blink-dev/c/Fku6784p0wI/m/3MyOMTk7BwAJ

This intent message was generated by Chrome Platform Status.

Mike Taylor

unread,
Apr 28, 2023, 10:08:37 AM4/28/23
to Di Zhang, blink-dev

On 4/27/23 5:28 PM, Di Zhang wrote:

Contact emails

hu...@chromium.orgxiaoc...@chromium.orgdizh...@chromium.org

Explainer

None

Specification

None

What's the reason for not having a spec? Is the idea that this is covered by this definition of a "focusable area": "the element is determined by the user agent to be focusable"

If we have multi-vendor alignment, maybe we can be more explicit than that?

(https://html.spec.whatwg.org/#focusable-area)


Design docs

None

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



Blink component

Blink>HTML>Focus

Search tags

tab keykeyboard focussequential navigation

TAG review

None

TAG review status

Not applicable

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)
Could you request a signal at https://github.com/WebKit/standards-positions? It's hard to know if Ryosuke's comment is still valid since he made it.


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.



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, Chrome OS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes
Mind giving a link to the tests?
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BSS7eBXci2n6rVdpLwWXgOmRrmkE%2BaxQGbq3dBwpmnyHOK9aA%40mail.gmail.com.

Di Zhang

unread,
May 1, 2023, 3:50:18 PM5/1/23
to blink-dev, Mike Taylor, blink-dev, Di Zhang

Right - the spec leaves it up to the UA to determine what is a focusable area. All browsers treat this a bit differently, and have typically considered that behavior to be up to the browser. For example, Safari has a user setting that can change what types of elements become keyboard focusable. So I'm guessing there will be pushback to standardizing this behavior. However, this is also why we don't believe there's a need to change the spec for this I2S.

Similarly, the written tests for this feature's changes are passing for Chrome, but not the other UAs. I have removed that check from this feature status and will update WPT accordingly.


On Friday, April 28, 2023 at 7:08:37 AM UTC-7 Mike Taylor wrote:

On 4/27/23 5:28 PM, Di Zhang wrote:

Contact emails

hu...@chromium.orgxiaochengh@chromium.orgdizhangg@chromium.org

Explainer

None

Specification

None
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Domenic Denicola

unread,
May 7, 2023, 9:51:34 PM5/7/23
to Di Zhang, blink-dev, Mike Taylor
Speaking with my HTML Standard spec editor hat on, I think it's appropriate for Chromium to ship this without spec changes, as Di explains.

Indeed, I'd be skeptical of changing the spec here. It might be worth opening an issue to discuss whether any changes are appropriate, but in general the spec is intentional about allowing each browser to make different choices on what it considers focusable, and in which ways things are focusable. So I'd anticipate no changes resulting from such an issue.


On Tue, May 2, 2023 at 4:50 AM Di Zhang <dizh...@chromium.org> wrote:

Right - the spec leaves it up to the UA to determine what is a focusable area. All browsers treat this a bit differently, and have typically considered that behavior to be up to the browser. For example, Safari has a user setting that can change what types of elements become keyboard focusable. So I'm guessing there will be pushback to standardizing this behavior. However, this is also why we don't believe there's a need to change the spec for this I2S.

Similarly, the written tests for this feature's changes are passing for Chrome, but not the other UAs. I have removed that check from this feature status and will update WPT accordingly.


On Friday, April 28, 2023 at 7:08:37 AM UTC-7 Mike Taylor wrote:

On 4/27/23 5:28 PM, Di Zhang wrote:

Contact emails

hu...@chromium.orgxiaoc...@chromium.orgdizh...@chromium.org

Explainer

None

Specification

None
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8e871d5b-f554-43df-92e7-f164a56972aan%40chromium.org.

Rick Byers

unread,
May 8, 2023, 7:00:23 AM5/8/23
to Domenic Denicola, Di Zhang, blink-dev, Mike Taylor
Thanks Domenic, that's helpful and makes sense to me. It's perhaps whether this is a "web exposed" change or not.

This sounds pretty safe to experiment with to me. Di please make sure behavior change is done behind a flag so we can 'kill switch' it if needed.

Perhaps the biggest compatibility risk here is the impact on assistive technology use cases? That's not something I feel equipped to have any judgement around. Have you talked with anyone in the accessibility team about this? Do we have any data or anecdotes on sites setting tabindex:0 on scrollers? Perhaps if that's already somewhat common place then that could reduce any fear dramatically?

I have a vague memory that "element is focusable" may be used in the tab highlighting algorithm. It may be worth a quick check to ensure that this doesn't cause highlights to show up when tapping on a scrollable region that has no other tap highlight candidates. I can help point you at the right code / people if desired.

Rick

Di Zhang

unread,
May 9, 2023, 6:15:32 PM5/9/23
to blink-dev, Rick Byers, Di Zhang, blink-dev, Mike Taylor, Domenic Denicola, Aaron Leventhal
Yes, this change is flagged behind the feature KeyboardFocusableScrollers (disabled by passing `--disable-blink-features=KeyboardFocusableScrollers`).

We have looped in aleventhal@ for similar accessibility concern. Aaron is the one who implemented the Keyboard Focusable Scrollers feature on Gecko years ago.
This feature (minus the "not contain any keyboard focusable children" rule) has existed in Firefox for +18 years now without any issue. Since assistive technology (for example screen readers) are using the same code for Firefox and Chrome, this should be low risk.

> I have a vague memory that "element is focusable" may be used in the tab highlighting algorithm. It may be worth a quick check to ensure that this doesn't cause highlights to show up when tapping on a scrollable region that has no other tap highlight candidates. I can help point you at the right code / people if desired.
Just to clarify, when you mention "tab highlighting algorithm", do you mean showing the orange focus ring when on mobile devices? I just tried with the feature on and off. In both cases, tapping doesn't show focus (no focus ring). As for using tab navigation, I see the same behavior as on the web. If feature is on, then an orange focus ring will show on the scroller.
If my understanding is wrong, please point me to the right code / people. Thank you




On Monday, May 8, 2023 at 4:00:23 AM UTC-7 Rick Byers wrote:
Thanks Domenic, that's helpful and makes sense to me. It's perhaps whether this is a "web exposed" change or not.

This sounds pretty safe to experiment with to me. Di please make sure behavior change is done behind a flag so we can 'kill switch' it if needed.

Perhaps the biggest compatibility risk here is the impact on assistive technology use cases? That's not something I feel equipped to have any judgement around. Have you talked with anyone in the accessibility team about this? Do we have any data or anecdotes on sites setting tabindex:0 on scrollers? Perhaps if that's already somewhat common place then that could reduce any fear dramatically?

I have a vague memory that "element is focusable" may be used in the tab highlighting algorithm. It may be worth a quick check to ensure that this doesn't cause highlights to show up when tapping on a scrollable region that has no other tap highlight candidates. I can help point you at the right code / people if desired.

Rick

On Mon, May 8, 2023 at 3:51 AM Domenic Denicola <dom...@chromium.org> wrote:
Speaking with my HTML Standard spec editor hat on, I think it's appropriate for Chromium to ship this without spec changes, as Di explains.

Indeed, I'd be skeptical of changing the spec here. It might be worth opening an issue to discuss whether any changes are appropriate, but in general the spec is intentional about allowing each browser to make different choices on what it considers focusable, and in which ways things are focusable. So I'd anticipate no changes resulting from such an issue.


On Tue, May 2, 2023 at 4:50 AM Di Zhang <dizh...@chromium.org> wrote:

Right - the spec leaves it up to the UA to determine what is a focusable area. All browsers treat this a bit differently, and have typically considered that behavior to be up to the browser. For example, Safari has a user setting that can change what types of elements become keyboard focusable. So I'm guessing there will be pushback to standardizing this behavior. However, this is also why we don't believe there's a need to change the spec for this I2S.

Similarly, the written tests for this feature's changes are passing for Chrome, but not the other UAs. I have removed that check from this feature status and will update WPT accordingly.


On Friday, April 28, 2023 at 7:08:37 AM UTC-7 Mike Taylor wrote:

On 4/27/23 5:28 PM, Di Zhang wrote:

Contact emails

hu...@chromium.orgxiaochengh@chromium.orgdizhangg@chromium.org

Explainer

None

Specification

None
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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+unsubscribe@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+unsubscribe@chromium.org.

Mike Taylor

unread,
May 10, 2023, 11:50:35 AM5/10/23
to Di Zhang, blink-dev, Rick Byers, Domenic Denicola, Aaron Leventhal

LGTM1

Daniel Bratell

unread,
May 10, 2023, 11:52:44 AM5/10/23
to Mike Taylor, Di Zhang, blink-dev, Rick Byers, Domenic Denicola, Aaron Leventhal

LGTM2

/Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37e97d89-ebe6-5403-d303-1bedb2e89524%40chromium.org.

Philip Jägenstedt

unread,
May 10, 2023, 11:52:52 AM5/10/23
to Mike Taylor, Di Zhang, blink-dev, Rick Byers, Domenic Denicola, Aaron Leventhal
LGTM2

On Wed, May 10, 2023 at 5:50 PM Mike Taylor <mike...@chromium.org> wrote:

LGTM1

On 5/9/23 6:15 PM, Di Zhang wrote:
Yes, this change is flagged behind the feature KeyboardFocusableScrollers (disabled by passing `--disable-blink-features=KeyboardFocusableScrollers`).

We have looped in aleventhal@ for similar accessibility concern. Aaron is the one who implemented the Keyboard Focusable Scrollers feature on Gecko years ago.
This feature (minus the "not contain any keyboard focusable children" rule) has existed in Firefox for +18 years now without any issue. Since assistive technology (for example screen readers) are using the same code for Firefox and Chrome, this should be low risk.

> I have a vague memory that "element is focusable" may be used in the tab highlighting algorithm. It may be worth a quick check to ensure that this doesn't cause highlights to show up when tapping on a scrollable region that has no other tap highlight candidates. I can help point you at the right code / people if desired.
Just to clarify, when you mention "tab highlighting algorithm", do you mean showing the orange focus ring when on mobile devices? I just tried with the feature on and off. In both cases, tapping doesn't show focus (no focus ring). As for using tab navigation, I see the same behavior as on the web. If feature is on, then an orange focus ring will show on the scroller.
If my understanding is wrong, please point me to the right code / people. Thank you




On Monday, May 8, 2023 at 4:00:23 AM UTC-7 Rick Byers wrote:
Thanks Domenic, that's helpful and makes sense to me. It's perhaps whether this is a "web exposed" change or not.

This sounds pretty safe to experiment with to me. Di please make sure behavior change is done behind a flag so we can 'kill switch' it if needed.

Perhaps the biggest compatibility risk here is the impact on assistive technology use cases? That's not something I feel equipped to have any judgement around. Have you talked with anyone in the accessibility team about this? Do we have any data or anecdotes on sites setting tabindex:0 on scrollers? Perhaps if that's already somewhat common place then that could reduce any fear dramatically?

I have a vague memory that "element is focusable" may be used in the tab highlighting algorithm. It may be worth a quick check to ensure that this doesn't cause highlights to show up when tapping on a scrollable region that has no other tap highlight candidates. I can help point you at the right code / people if desired.

Rick

On Mon, May 8, 2023 at 3:51 AM Domenic Denicola <dom...@chromium.org> wrote:
Speaking with my HTML Standard spec editor hat on, I think it's appropriate for Chromium to ship this without spec changes, as Di explains.

Indeed, I'd be skeptical of changing the spec here. It might be worth opening an issue to discuss whether any changes are appropriate, but in general the spec is intentional about allowing each browser to make different choices on what it considers focusable, and in which ways things are focusable. So I'd anticipate no changes resulting from such an issue.


On Tue, May 2, 2023 at 4:50 AM Di Zhang <dizh...@chromium.org> wrote:

Right - the spec leaves it up to the UA to determine what is a focusable area. All browsers treat this a bit differently, and have typically considered that behavior to be up to the browser. For example, Safari has a user setting that can change what types of elements become keyboard focusable. So I'm guessing there will be pushback to standardizing this behavior. However, this is also why we don't believe there's a need to change the spec for this I2S.

Similarly, the written tests for this feature's changes are passing for Chrome, but not the other UAs. I have removed that check from this feature status and will update WPT accordingly.


On Friday, April 28, 2023 at 7:08:37 AM UTC-7 Mike Taylor wrote:

On 4/27/23 5:28 PM, Di Zhang wrote:

Contact emails

hu...@chromium.orgxiaoc...@chromium.orgdizh...@chromium.org

Explainer

None

Specification

None
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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.
--
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.

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/37e97d89-ebe6-5403-d303-1bedb2e89524%40chromium.org.

Daniel Bratell

unread,
May 10, 2023, 11:54:49 AM5/10/23
to Philip Jägenstedt, Mike Taylor, Di Zhang, blink-dev, Rick Byers, Domenic Denicola, Aaron Leventhal

Make that LGTM3 from me. Good luck shipping!

/Daniel

Reply all
Reply to author
Forward
0 new messages