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

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-ui] `interactivity: focusable` ==
## Motivation

The ability to make elements focusable via CSS has [come up before](https://github.com/w3c/csswg-drafts/issues/3379) by @frivoal.

There is already precedent in controlling focusability via CSS, just not directly, but as a side effect of _other_ features: `overflow: auto / scroll` makes scroll containers focusable, but only when there is something to scroll ([demo](https://codepen.io/leaverou/pen/PwPpVBJ)).

Additionally, there is precedent of CSS introducing non-focusable interactive features, which is an a11y footgun: 
* `resize` introduces interactive UI that manipulates CSS properties, but is not keyboard focusable
* `:hover` allows creating interactive UIs very easily, but there is no way to make them keyboard accessible without HTML changes and/or JS, which is an a11y footgun. Authors should not be forced to choose between DX and accessibility.
* We’ve recently discussed [`image-animation`](https://github.com/w3c/csswg-drafts/issues/1615), something like this could make it incredibly more useful.
* It is very common to have content that only becomes interactive under certain conditions, e.g. smaller screen sizes.
* Making generated content focusable would obliterate a lot of specialized pseudo-elements being proposed (especially if down the line we can control ARIA roles too)

## Proposal

We now have an [`interactivity` property](https://drafts.csswg.org/css-ui-4/#propdef-interactivity) that only goes the other way with `interactivity: inert`, so adding an `interactivity: focusable` value seems like the natural next step. Presumably any philosophical arguments around controlling focus with CSS would have also applied to that.

We could later even add more granular controls to facilitate patterns like tabs, radios etc.
But as an MVP, even the very simple ability to make an element focusable would eliminate a _ton_ of custom code, and would make it much easier for authors to create accessible experiences.

Certain combinations of other properties & values could make `interactivity` compute to `focusable` (e.g. `overflow: auto`).

Because this is dynamic, it can also be used as a primitive to implement other features (e.g. `focusgroup`).
E.g. it’s conceivable this could be part of the UA stylesheet even:

```css
[tabindex=0] { /* or [tabindex >= 0] if #354 moves forwards */
 interactivity: focusable !important;
}
```

## Issues

- While this makes it easier to create keyboard accessible experiences, with no ability to assign other ARIA attributes, it could be a false sense of security ("oh my popup menu is keyboard accessible, I don't need to do anything else"). But the way to solve this is to provide control over those as well, not to make it harder to make a UI keyboard accessible.
- This would preclude a [`:focusable`](7269) selector, as it would now be cyclical. However, I think the value of this is worth it. We can always design a slightly different version of `:focusable` that is not affected by CSS to solve the core problem that proposal is addressing. And given that there are already CSS properties that affect focusability, that ship has probably sailed anyway.


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13040 using your GitHub account


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

Received on Thursday, 30 October 2025 16:39:21 UTC