Upcoming focus navigation change in Chromium

[boghyon]

Background

Some years ago, I had submitted this issue on Chromium bug tracker: https://issues.chromium.org/issues/40113891
As a result, Chromium has now improved the keyboard a11y by allowing scrollable containers to be in the focus chain (unless tabindex < 0), similar to Firefox.

I.e. when tabbing through:

• If the scrollable container has tabindex ≥ 0, move the focus to the container.
• If the scrollable container has tabindex < 0, skip the container.
• If the scrollable container has no tabindex:
  • Chromium [new]: move the focus to the container but only if the container does not contain any focusable element. E.g. if the container contains only texts. Otherwise, skip the container but jump to the inner focusable element directly. The container can still be keyboard scrolled with the focus there.
  • Firefox: move the focus to the container regardless whether the container has a focusable element or not.
  • Safari: ...? "Safari has a user setting that can change what types of elements become keyboard focusable" according to the discussion in the Blink dev group linked below.

Steps to reproduce

1. Start Chrome. If the new change is not already enabled by default:
   1. Kill all Chrome instances that are still running.
   2. From a CLI, navigate to the directory where the Chrome executable is located.
   3. Start Chrome with the option --enable-blink-features=KeyboardFocusableScrollers.
2. Open https://output.jsbin.com/yajesab
3. Move the focus to the scroll area with the keyboard which is possible now thanks to the Chromium change.
   Issue: the focus indicator is unstyled in UI5.

Request to consider

• Deprecation: the focusable property of the sap.m.ScrollContainer can be deprecated since the browsers supported by UI5 set the focus automatically depending on the container content and the tabindex.
• Fixes:
  • sap.m.PageRenderer currently avoids being in the focus chain only in Firefox.
    

    openui5/src/sap.m/src/sap/m/PageRenderer.js

    Line 152 in d5f5e16

    if (Device.browser.firefox) {

    In my view, this special handling needs to be removed, allowing the default browser behavior to take effect.
  • Unstyled focus indicator when the Page receives the focus and scrolls. This was initially reported in the past (sap.m.ScrollContainer & .Page: missing focus indicator for scroll content #2785) but was closed with the above special handling for Firefox.

Remaining questions

• What is the exact behavior in Safari regarding this topic? Does Safari need a special handling in UI5?
• Is the behavior of the browsers same across all OS supported by UI5? Any system settings that could affect?

More information

"Intent to Ship: Keyboard-focusable scroll containers" - "Blink-dev" group
Changes regarding the topic KeyboardFocusableScrollers - "Blink Reviews" group

[tsanislavgatev]

Hello @boghyon ,
Thank you for sharing this finding. I've created an internal incident 2370139540. The status of the issue will be updated here in GitHub.
Regards,
Tsanislav

[hristop]

Hi @boghyon ,

We will handle this via internal BLI: BGSOFUIRILA-3736 as it will require some support from our design colleagues as well.
I will close this issue, but you can monitor the progress via the BLI.

Best Regards,
Hristo

[boghyon]

• According to https://www.youtube.com/watch?v=Io5d28IETrg&t=187, the change regarding the keyboard focusable scroll containers is planned to be available in Chrome 124. Nice to see my feature request getting extra announcement :)
• According to https://www.youtube.com/watch?v=H9wwThDLGIs&t=131s, the change is enabled by default since Chrome 127. My initial bug report https://issues.chromium.org/issues/40113891 is also finally closed.

The feature is described more in detail at Keyboard focusable scrollers | Blog | Chrome for Developers