Clarify focusing behavior of scrollable area

[TakayoshiKochi]

In the current spec, scrollable area is included in focusable areas:
https://html.spec.whatwg.org/multipage/interaction.html#focusable-area

However, while surveying the behavior of modern browsers, I found they work quite differently.
Details at https://bugs.chromium.org/p/chromium/issues/detail?id=585413#c2

There seems to be several separate issues involved:

• Should TAB keyboard navigation should visit scrollable area?
• Whether or not Document.activeElement point to scrollable area (corollary: :focus match to the area?)
• Should clicking within a scrollable area focus the area?
• Should clicking/dragging the scrollbar blur the original focus (when the area does not have focus)

[annevk]

See also the discussion in #938 about how focus needs to be revamped. I don't really have bandwidth to work on it though.

[hugoholgersson]

Should TAB keyboard navigation should visit scrollable area?

I really think so. Otherwise, clipped text in some overflow-divs won't be readable for users who can't, or doesn't want to, use a mouse to click+scroll the area.

Can we agree to that the current spec holds => scrollers should have tabIndex=0?

I need to confirm this before I fix this in Chrome and submit bugs on Safari and Edge.

[domenic]

From what I can tell there are a few things going on here.

• The current spec says that scrollable areas "can" be focusable areas. (It literally uses the word "can"; not sure how to interpret that.)
• The current spec says that elements with their tabindex focus flag set "can" be focusable areas.
• The spec differentiates between being a focusable area, and being reachable via sequential focus navigation (TAB key). These are independent.

But there's nothing that says that scrollable areas should have their tabindex focus flag set (i.e., what you refer to as tabIndex=0). And there's nothing saying that they should be reachable via sequential focus navigation. There's clauses that allow the UA to do either, if it wants, but nothing requiring it.

It could be nice to tighten up the spec in various ways. But I think the current intent is to allow UAs to make their own choices on different axes. So you can change Chrome, and maybe file FYI bugs on browsers, but not sure what we should do the spec level.

[hugoholgersson]

Edge bug: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/19394675/
WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=190870

[domenic]

I think with 1ab7c86 this is as defined as it is going to get. Browsers still want the freedom to choose whether something is focusable, and if so, in what ways, so we're not going to be able to say scrollable areas are always one way or another in the spec. But the spec now has infrastructure for precisely choosing the behavior, and e.g. how this impacts the tabIndex getter (it doesn't).