[css-nav-1] Clarify the condition of focusable element

[jihyerish]

Currently, the spec defines the focusable elements depending on the HTML Spec.

But there are some missing parts for considering what is focusable for the spatial navigation.
For example, the element specified with "visibility: hidden", is it a focusable or not?
This matters when we get the result of focusableAreas({ mode: "all" }), the result will include
the elements with visibility: hidden or display: none.

There is more detailed description about the Focusable Element.
: https://allyjs.io/data-tables/focusable.html#css-property-visibility

We need to refer it and make it clear about the condition of focusable in the spatial navigation.

[jihyerish]

The additional condition needs to be considered:

• The element which uses keydown event handler

Also, we need to follow up the discussion whatwg/html#4464 in WHATWG

[hugoholgersson]

For example, the element specified with "visibility: hidden", is it a focusable or not?

IMO, things users can't see should not be navigable.

Nodes with a key- or click handler most likely needs to be navigable.

Some web apps use one "catch all"-click handler, often put on body or a container div, to react on clicks within certain sub areas of the page. These web apps often lack tab indices. Instead, clickable/focusable elements, for example divs that look like buttons, are styled with cursor: |pointer|. To enable SpatNav on these web apps, let's add cursor: pointer to the list too? (Chrome implementation).

[bokand]

I don't think we need to redefine what it means to be focusable. We should instead restrict spatial navigation such that "focusable" is required but not sufficient. i.e. The element must be focusable as well as visible. I believe Chrome's implementation already does this.

[jihyerish]

I agree that in the spatial navigation spec, we don't need to redefine the "focusables".
But I'll consider putting a note that UA can make the element with

• keydown event handler
• {cursor: pointer}, click event handler (especially for the page in TV)

[hugoholgersson]

But I'll consider putting a note that UA can make the element [a "SpatNav candidate"] with

• keydown event handler
• {cursor: pointer}

Cool. Yeah, I think that's a good to mention in the spec.

In Chrome, this is not only on "keydown" but also on "keyup", "keypress" and on "click". See https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/dom/element.cc?type=cs&q=function:SupportsSpatialNavigationFocus&sq=package:chromium. I think we should mention all of them, in that case.

I also think we should mention that tabindex=-1 can be used to override this heuristics. I encouraged one major web app to use this trick on their topmost container <div> that had a click-handler (to stop chromium's SpatNav from going to there). They now use it in production. I'd like to add a web test for that.