Components: `:focus` → `:focus-visible`

[jameskoster]

Focus rings add noise the UI which can be distracting or confusing when not serving a practical purpose (see https://github.com/WordPress/gutenberg/issues/61085).

Let's discuss applying focus styles to :focus-visible rather than :focus. This would ensure that visual details like focus rings only appear when most useful, IE when navigating via keyboard.

[mirka]

I don't think we should do this in a blanket way, as in using :focus-visible by default. I think the idea is that even if a user did something with a mouse one time, it doesn't mean that they won't later resume what they're doing with a keyboard. So there is usually value in showing where the focus is at any time.

Rather, I think we should use :focus-visible only in cases where specifically bad things happen when using :focus, and the downsides of the focus ring not being visible are negligible. Which is the case with the DropdownMenu in #61085, where the focus ring is causing confusion, and the dropdown will hide on click anyway so the focus ring doesn't need to persist.

[jameskoster]

I don't disagree but that might be tricky to manage holistically because good/bad is situational?

Another good example is the back button in in global styles (Navigator component):

When using a mouse/trackpad it is overly prominent and distracting which we might consider to be bad; but based on your point about the user potentially switching to keyboard this would be considered good.

Come to think of it, doesn't the menu example also fall foul of your suggestion if we use focus-visible? If I open the menu with my mouse but switch to keyboard then I don't know where focus is until I press a key 🤔

[mirka]

that might be tricky to manage holistically because good/bad is situational?

Definitely, I don't think we can have a clear rule in place that would be globally applicable. Fortunately I think these decisions will usually only need to be made at the wp-component level, and not in normal app code. So we can afford to have nuanced discussions and make decisions on a case-by-case basis.

Or do you think it would be possible/better to just default to :focus-visible for everything? Not saying that's outside the realm of possibility, but WP in its current state is pretty consistent about always showing focus rings (more than the average web app, I would say), so it would be a big departure. And apparently there's also a concern that "it may not be obvious as to why the focus indicator is appearing and disappearing if a person is using mixed forms of input".

There are probably no easy answers here, as decreasing cognitive load in one way could increase it in another 🙁 We'll just have to weigh our options as best as we can.

Come to think of it, doesn't the menu example also fall foul of your suggestion if we use focus-visible? If I open the menu with my mouse but switch to keyboard then I don't know where focus is until I press a key 🤔

Sure. But I think I consider a dropdown menu flow to usually be an uninterrupted chain of events, so it's less likely that a user's attention would get lost during that.

[jameskoster]

Maybe it's something we discuss on a per-component basis then, informed by existing in-product issues.

To be honest, most components are probably fine to use :focus, but Button can be a bit troublesome... There's the global styles example outlined above, but several other issues where the focus ring is adding noise / distraction when navigating by mouse and trackpad.

Dropdown menus

https://github.com/user-attachments/assets/91bb3035-150b-49a8-8aa1-dc4b8795eadb

• Flash of focus ring around button before menu opens feels buggy
• Focus ring after closing the menu isn't very helpful in this context

Panel titles

Site icon

• When exiting the full screen editor the site icon has too much visual prominence.

Modal focusOnMount

The tertiary button here has too much visual prominence by virtue of the focus ring:

---

It's interesting to note that other systems do not always blanket-apply one way or the other. It's not uncommon to find :focus-visible used for buttons and :focus for other input types.

It'd be good to get feedback from the accessibility team on this, but perhaps we could try applying button focus styles to :focus-visible?

[ciampo]

Could have a ":focus-visible by default" approach, and use :focus only where we think it's needed?

[jameskoster]

I'm kind of leaning in the opposite direction :D :focus by default, and switch to :focus-visible when focus rings are causing issues for mouse interactions.

To be honest switching Button to :focus-visible would resolve the vast majority of the current grievances. Maybe we start there?

[ciampo]

:focus by default, and switch to :focus-visible when focus rings are causing issues for mouse interactions.

That would also make sense, especially since it would represent a gradual change from what we already have in the codebase.

To be honest switching Button to :focus-visible would resolve the vast majority of the current grievances. Maybe we start there?

That's going to be tricky especially given all the high amount of style overrides ( 😢 ) aimed at tweaking Button — there is risk of introducing many visual regressions.

[joedolson]

The problem with :focus-visible is that it only appears when a user is using a keyboard. It doesn't appear for touch users, voice command, screen reader users who are sighted and navigating using their reading tools, etc. It basically creates a less reliable management of visible focus.

I think there may be selective cases where :focus-visible can be used, but I'm not sure that applying it globally is a good idea.

One thing in particular is that a focus ring is very important anytime focus is moved. E.g., if you close a modal and focus is set somewhere - that focus ring is very important, so that a user can figure out where they are now.

I think that making a global change to focus styles is a high risk for introducing UX regressions, and would decrease overall accessibility. Some selective changes are possible, but anything global would require extensive testing.