[css-nav-1] FocusTraversal API

[arei]

Generally speaking, there is a lot of overlap here with the recent proposal of the FocusTraversal API in the WICG incubator discussion group. I think there's a chance to work together to support both end goals, but with two different specs that work in concert instead of competition.

If someone could have a look at the FocusTraversal API explainer I would definitely be interested in further conversation around the subject.

https://github.com/awesomeeng/FocusTraversalAPI/blob/master/EXPLAINER.md

[AmeliaBR]

cc @frivoal @jihyerish

[jihyerish]

Thank you for the great input!
I guess the FocusTraversal API is proposed for the sequential navigation (navigation with Tab key), but there are some features which are also needed in the spatial navigation.

There are APIs in Spatial Navigation Spec that match with the part of FocusTraversal API.

• window.navigate(dir)

  • Move the focus to the next focusable element with the given direction
  • dir is left, right, up or down.
  • Matchs with FocusTraversal API :
    window.focusManager.forward(), window.focusManager.backward()

• Element.spatialNavigationSearch(option)

  • Returns the element which will gain the focus from the target element
  • With option , the navigate direction(dir) can be specified
  • Matches with FocusTraversal API
    : window.focusManager.next(element), window.focusManager.previous(element)

• Element.focusableAreas()

  • Finds focusable elements within the target element
  • Matches with
    : window.focusManager.isFocusable()
    • This isn't the perfect match, but I add this those are related. Because Element.focusableAreas() needs isFocusable().

More about isFocusable(), there is a polyfill of the spec and the polyfill also has isFocusable() function.
When I implemented this function, I referenced the definition of focusable areas in HTML Spec.
But it was hard to simplify the implementation, so I also referenced Focusable Elements - Browser Compatibility Table.
I'm open to considering this API as a standard API.

I've noticed that there are on-going discussions about the clarifying the focusable and considering overall focus in HTML spec. (Oh, you have already joined the discussion!)
Maybe isFocusable() can also be related to this discussion.

I'm also interested in window.focusManager.previouslyFocused and window.focusManager.history,
because those features - saving the track of the focus movement- are also in my list for future standard API proposal. : )

[arei]

@jihyerish Do you see anything else in spatial navigation that would be better suited to FocusTraversal?

[jimmyfrasche]

@arei I like this and have wanted this multiple times, especially forward().

focus, forward, and backward should take the same options as element.focus() but did not see that mentioned anywhere.

One thing that I don't see a simple way to do is to get the first or last focusable element of a container. I can't think of a use for last at the moment, but first would be useful for cases like opening a dialog-type element and focusing the first element. If not provided an element, those could return the first and last focusable element of the document.

Similarly, orderedElements could take an optional element to search in, defaulting to :root.

What is the use case for the history list and why is a small library that records the focus events insufficient? (Since intent can be hard to read over the internet, let me clarify that I am genuinely curious and interested).

[arei]

@jimmyfrasche I have taken your suggestions and integrated them into the explainer. The polyfill will get an update soon as well.

As for the use case for history I dont specifically have one; more I just like the idea of being able to do it and I think its relatively cheap. There could be some value in focus trap behavior.