... 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.
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.
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.
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?
@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.
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
Matthe: Marcos suggested "overcome by events"... we could go with that... If we were going to do this... it would be a good idea to "focus" on specific areas or divide between us. But there has to be some sort of goal... There's a lot of new stuff coming out of OpenUI... is there guidance we should provide?
Jeffrey: I wouldn't suggest "overcome by events" ... because things haven't changed... we just haven't had time to do it... Maybe ask an a11y groupt to look at it and then we could promote into a finding?
Matthew: lots of stuff from OpenUI has come through... we don't want to invent work that doesn't need to be done. clear scope of what is needed would be good.
Jeffrey: I feel like the most likely problems are in the stuff that hasn't been touched recently... probably there are "dusty corners".. we need to look at a lot of things... not sure it's worth it.
Dan: any design principle?
Jeffrey: we could ask APA if they think there is a principle here?
Matthew: it's worth asking... the specific people in APA that do hands-on stuff in this area... I'm not sure how easy it would be to coordinate a more systematic review across html...
Dan: suggests changing the focus of the discussion to the design principles ... maybe opening up a new issue in that repo and closing this issue
Matthew: we do have access to a lot of academic research in this area... so there might be some stuff we can get from that to.
Matthew: didn't we say this was overcome by events? We talked about this approx a million years ago. Are we concerned that something has come up about this?
Hadley: it looks like it fell into the abyss...
Jeffrey: because Alice filed it and Alice worked a lot on focus... that's how that happened. It's true that focus is inconsistent on the web ... and it would be good to review... Matthew indicated that APA might take it... I think we should close.
Hadley: I think we should close as well.
Jeffrey: It still ought to happen... we're just not going to be able to get to it...
Hadley: leaves a closing comment indicating that we encourage anyone who does look at this topic to bring it to us.
OpenedJan 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.