[css-ui] `interactivity: focusable`

[LeaVerou]

Motivation

The ability to make elements focusable via CSS has come up before 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).

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, 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 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:

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

[Loirooriol]

overflow: auto / scroll makes scroll containers focusable

It seems the scroll container is sequentially focusable, but not click focusable.

I'm not sure what kind of focusability you want for interactivity: focusable.

• Focusable: yes (otherwise it can't be sequentially nor click focusable).
• In the document's sequential focus navigation order: ?
  If so, how is it ordered?
• Sequentially focusable: ?
• Click focusable: ?

And would interactivity: focusable work on pseudo-elements?

[LeaVerou]

@Loirooriol

I'm not sure what kind of focusability you want for interactivity: focusable.

I intentionally did not go in the weeds, as (from memory, which can be faulty) most use cases I’ve come across have just needed some way, any way to make elements focusable via CSS, rather than depending on a particular answer to these questions.

That said, it may be helpful to frame it in terms of requirements / considerations. E.g. for sequential-only vs click-focusable-too:

• Presumably down the line we'd want to expose more granular controls, but for the initial MVP it’s a safer bet to err on the side of more accessibility. That points towards both.
• A good mental model for authors is that it works like tabindex=0, which would also point towards both.
• Providing independent value rather than being a CSS-based way to accomplish things that are already possible is also appealing. That would point towards sequentially focusable only.
• If focusable is framed as the opposite of inert, that also points towards both.
• Click-focusable as well enables more UX patterns, and noise from superfluous visible affordances can largely be avoided through :focus-visible, which also points towards both.

So it seems like there is stronger motivation to start with both and provide more granular control after, but if sequential-only is easier to implement for UAs (since that's what the precedent is about), I think that would still be immensely useful.

We could write a similar list for navigation order, but the same order as tabindex=0 seems like a good starting point for the MVP and something that is already well-defined.

And would interactivity: focusable work on pseudo-elements?

Absolutely, that’s a core use case!

[Loirooriol]

It's not uncommon to use tabindex="-1" in HTML, so I think authors should be able to make the element click focusable but not sequentially focusable.

And I tend to think that if authors can make an element sequentially focusable, they should be able to specify the tabindex.

I don't think pseudo-elements are currently focusable. That would need to define what to do with document.activeElement and whatnot.

[LeaVerou]

It's not uncommon to use tabindex="-1" in HTML, so I think authors should be able to make the element click focusable but not sequentially focusable.

And I tend to think that if authors can make an element sequentially focusable, they should be able to specify the tabindex.

All of these are useful things, eventually. But do you think they are as frequently needed as tabindex="0"? I think we can address a lot of use cases with something that behaves like tabindex="0" and once we have something in, it’s much easier to expand it to be more granular.

I don't think pseudo-elements are currently focusable. That would need to define what to do with document.activeElement and whatnot.

There are pseudo-elements that are currently focusable, ::scroll-button() is one that comes to mind. For that, document.activeElement points to its host element. This is how overflow behaves as well when it makes an element focusable (testcase). I agree it would be better to have a way to find out which pseudo-element is active, but I don't think it’s a blocker.

[Loirooriol]

it’s much easier to expand it to be more granular.

I think we need to consider plausible future extensions when designing the basic syntax. If we end up allowing to set the index for sequential focusability, then we should maybe add tab-index: none | <integer> now and not bother with interactivity: focusable.