sap.m.ScrollContainer & .Page: missing focus indicator for scroll content

[boghyon]

URL (minimal example if possible)

E.g.: https://openui5nightly.hana.ondemand.com/entity/sap.m.Page/sample/sap.m.sample.PageFloatingFooter

Steps to reproduce the problem

1. Open the above sample page
2. With the keyboard, Tab through elements until it reaches the page

What is the expected result?

Since the scroll content is an interactive element (scrollable with arrows, Home, End, etc.), the focus indicator should be visible there too, according to WCAG 2.1 Focus Visible SC 2.4.7 (Level AA):

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

What happens instead?

• UI5 outline style is not applied to the scroll content. Instead, we see UA's default focus indicator.
• When focused with a mouse, there is no focus indicator at all which is inconsistent with Feature request: Display outlines only at keyboard interaction #1289 (comment).

Any other information? (attach screenshot if possible)

In Chrome, for example, we see a blue outline:

A similar issue can be observed with sap.m.ScrollContainer.

[boghyon]

Another case:

1. Open https://openui5nightly.hana.ondemand.com/controls (The focus is set on the search field).
2. Press Tab three times.

Now the user needs to guess where the focus went.

[boghyon]

Never mind. Just realized that I had a flag^[1] enabled in Chrome which caused this issue. Sorry!

---

[1] The flag was #enable-experimental-web-platform-features.

[boghyon]

Ok, the issue is actually reproducible in clean-installed stable Firefox (72.0, Windows). FF behaves like Chromium-based browsers with #enable-experimental-web-platform-features, just without the blue focus indicator when the scroll area is focused.

[a-z-ivanov]

Hi boghyon,

The Page from the sample is a container that does not receive the focus. Like many other containers, it is just a div in the DOM, not focusable by default. Same as the page here, many posts, but the body does not receive the focus, or have an indicator. It reacts to the arrow down events, because they bubble through all non-scrollable children. So we could say that it does not need the focus to be interactive.

E.g. The focus is on the 'Comment' button when I hold arrow up and the page scrolls.
When the focus is on the text area the cursor moves inside and the page does not scroll.

A sap.m.ScrollContainer, on the other hand, is a container designed to receive the focus on demand. Its API includes a property 'focusable'.

Regards,
Alex

[boghyon]

Hi Alex, thanks for the response.

It's true that divs shouldn't be focusable technically. But what's weird is that Firefox requires an additional Tab press to reach the [Toggle floating footer] button whereas other browsers don't.

This leads to the issue mentioned in #2785 (comment) where FF users lose the track of focus indicator when tabbing through, since the scroll area itself gets the focus beforehand without any indicator. In other browsers, it's always clear where the focus indicator is.

I guess this is a FF issue. Not sure if UI5 should do anything about it.

[a-z-ivanov]

There is some more info. I think we need to workaround this table, to make the experience the same in all browsers:

https://allyjs.io/data-tables/focusable.html

Our element is an overflowing <section style="overflow: scroll">
It's documented as 'tabbable' in FF.

[IlianaB]

Hello @boghyon ,

We've created an internal incident 2080023882 to investigate this problem. The status of the issue will be updated here in GitHub.

Regards,
Iliana

[boghyon]

Researched a bit more ...

• The behavior in FF, making containers with scrollbars tabbable (not just <section> with overflow), is by design (source).
• Chromium intends to adopt Firefox's behavior:

  This CL mimics Firefox's behavior; all content in scroll
  containers are now keyboard-accessible [...]. Without this fix, some scrollers' web content is not accessible at all without a mouse pointer (source).

• But due to a regression, it's currently not yet enabled by default:

  Disable Blink's KeyboardFocusableScrollers by default. The original change at r608013 caused WebUI regressions, some of which are unclear on how to fix because of a separate issue with tabindex -1 and Custom Elements [...]. Need to address WebUI affected cases, before the flag is re-enabled by default (source).

Not sure the table is reliable since it's is no longer maintained and Chromium's behavior might change...

[terezamch]

Hello @boghyon ,

Seems like the issue is fixed by the linked above change. Therefore I am closing the issue.

Best regards,
Tereza