Review the HTML spec's treatment of focus

[alice]

There has been work recently, e.g. whatwg/html#4754, to give the HTML spec a more consistent handling of focus.

We should check what the status of that work is, whether it is being tracked in a single place, and review the work as a complete set once it's done.

[alice]

From @rakina, some starting points:

https://blog.whatwg.org/focusing-on-focus
whatwg/html#4607

[alice]

See also: WICG/webcomponents#762

[alice]

See also: whatwg/html#5326

[alice]

Looking at this in our virtual face to face just now, I have some relatively unstructured thoughts:

If we were adding keyboards as a new usage mode on the web today (as a highly unlikely counterfactual), we would suggest writing an explainer outlining the user needs, the platform constraints, and how the proposed design meets those user needs. It seems like the work done on focus in the HTML spec has only outlined the (no longer proposed, but factual) design, without explaining how it fits together, documenting any regrettable decisions, or any user needs which should be taken into account when designing additions to the system.

In particular, the decision to have :focus match on unfocusable shadow hosts when the "actual" focused element is inside a shadow root seems to have made a priority of constituencies trade-off in the dispreferred direction: in order to avoid potentially revealing the existence of a shadow root (theoretical purity, or at best convenience for developers), it shows a focus highlight by default on the shadow host, creating a confusing experience for users.

A much older feature, tabindex=-1, also has some regrettable aspects:

• It is impossible to tell from the IDL tabIndex attribute whether an element is unfocusable, or is only programmatically focusable
• It causes the element to be focused on click, which is useful in some but not all cases.

I began some work to explore the needs which tabindex=-1 is attempting to address in WICG/webcomponents#762 (comment), but it would be good to have a full-fledged "focus on the web" explainer which explains in terms of user needs, rather than simply explaining the state of the spec right now.

[hober]

@alice wrote:

but it would be good to have a full-fledged "focus on the web" explainer which explains in terms of user needs, rather than simply explaining the state of the spec right now.

Do you think the TAG should be trying to find someone in the community (@rakina, maybe, or someone from WAI) to write such an explainer?

[atanassov]

@travisleithead (nudge :)) could also help us make progress on this given his experience in both DOM and accessibility space. Or help find someone who could offer some time for this.