#468: Review the HTML spec's treatment of focus

Visit on Github.

Opened Jan 27, 2020

There has been work recently, e.g. https://github.com/whatwg/html/pull/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.

Discussions

Comment by @alice Jan 28, 2020 (See Github)

From @rakina, some starting points:

https://blog.whatwg.org/focusing-on-focus https://github.com/whatwg/html/issues/4607

Comment by @alice Mar 2, 2020 (See Github)

See also: https://github.com/w3c/webcomponents/issues/762

Comment by @alice Mar 2, 2020 (See Github)

See also: https://github.com/whatwg/html/issues/5326

Discussed Nov 1, 2020 (See Github)

Deferred since Tess was unavailable.

Discussed Jan 1, 2021 (See Github)

Alice: Looked at the PR on making :focus match on shadow hosts... https://github.com/whatwg/html/pull/4731

... This decision seems to have been made for reasons which conflict with the priority of constituencies: it shows a confusing focus style to users in order to avoid revealing the existence of a shadow root.

... I would have liked to see an explainer of user needs and platform constraints which led to the current design, as well as a description of the current design.

... In particular, tabindex=-1 is more or less a historical accident due to some ancient behaviour in Internet Explorer, and there is no way to tell from the IDL tabIndex attribute whether an element is programmatically focusable, or not focusable.

... I started trying to explore the needs for this feature in https://github.com/WICG/webcomponents/issues/762#issuecomment-692416176 and a later comment on that issue, but it would be good to have a full "focus on the web" explainer.

Comment by @alice Jan 26, 2021 (See Github)

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 https://github.com/WICG/webcomponents/issues/762#issuecomment-692416176, 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.

Discussed Feb 1, 2021 (See Github)

Skipped.

Tess: I should schedule a breakout with someone to take another look at this one with me. I'll ask for a volunteer at the plenary.

Discussed May 1, 2021 (See Github)

Rossen: Did another read through the issue and linked documents. The state of focus in HTML is still incomplete. As originally pointed out by Alice, we should continue/complete this review once the linked work matures.

Discussed Dec 1, 2021 (See Github)

Rossen: there's nothing easy about this issue. Deserves an entire breakout, at least one hour, between Tess and myself.

Comment by @hober Jul 27, 2022 (See Github)

@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?

Comment by @atanassov Jul 27, 2022 (See Github)

@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.

Discussed Oct 1, 2023 (See Github)

Rossen: not sure where this is going. No engagement from anyone in accessibility or DOM space. There was some initiative by rakina .. nothing from pinging people. Bigger motivation at the time was the way the different implementations were handling focus. Discrepency between trident and gecko and blink/webkit. Blink/webkit focus management was pretty consistent. Not the case with gecko and trident. Since then trident is no longer. Don't recall the differnce between gecko and blink and webkit.. the rest is trying to essentially clarify how does the focus element vs tab index vs active element internally represented and how is it exposed to the web. That's the write up that we were asking for so we can have a better explainer. We can close it.. keeping it open hasn't resulted in anything fruitful.

Peter: nice to not have this hanging over, but we could wait until spring and see if anyone new wants to move it forward

Discussed Jan 1, 2024 (See Github)

reassigned to Matthew & Tess

Both 525 & 468 assigned to TAG future discussion - added "deep thoughts" TAG