Re: [csswg-drafts] [css-ui] `interactivity: focusable` (#13040)

I'd like to +1 @jyasskin's comment on preferring to start this with use cases that need to be solved -- and ideally also some evidence behind why those use cases are a widespread or severe issue, particularly because changing this incurs significant risk of creating new problems. In this case, this is further compounded by the fact that the new problems being created would be felt by users, in service of attempting to solve pain points felt by developers.

I think ideally this should also be raised somewhere other than the CSSWG, since the question of how to improve the DX of focus management is not strongly tied to CSS, if we don't start with this specific solution. At a more practical level, fewer accessibility people are involved in CSS as compared to Open UI or HTML. Since managing focusability is pretty strongly rooted  in accessibility, I think the solution should be heavily influenced and worked on by that community.

I personally have never come across a case where I felt focusability would be more robustly handled in CSS, as compared to HTML or JS. While there may be instances where updating focusability in CSS easier to do at the time of authoring, it is fundamentally more fragile and harder to debug and maintain. My take is that this is because focusability is strongly tied with both semantics and scripted interactivity, and only loosely correlated with presentation. Even the use case @LeaVerou brought up in https://github.com/w3c/csswg-drafts/issues/3379#issuecomment-2170356635 makes that clear:

>  E.g. one can use CSS to make a panel show or hide depending on activity on some other part of the page. In those cases, you'd want to make the trigger focusable, but that cannot be done with CSS alone.

This is an already-existing mistake from developers who do not understand accessibility. They often want to just turn on or off the focusability of a control, because a quick keyboard-only, surface-level understanding makes that seem like focusability is all that's needed to make something accessible. This is not at all true, and people who take this approach make accessibility worse for screen reader and voice control users. This proposal seems like an alarmingly large foot-gun that would increase the frequency of this mistake.

There are definitely things that can be done to improve the DX of focus management, and there is already work being done in other areas to do so (e.g. `focusgroup` or `focusNext` in Open UI, as well as adding new or improved elements so devs no longer need to roll their own). The process for those has been much more rooted in talking with accessibility folks, and (at least in my personal opinion) their design is much better for having made that an early part of the process.

-- 
GitHub Notification of comment by smhigley
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13040#issuecomment-3487928582 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 4 November 2025 20:38:07 UTC