Admin bar: Command palette button retains focus styles after closing

[juanfra]

The command palette trigger button in the admin bar keeps visible focus styles (with midnight blue is quite visible) after the palette is closed, regardless of whether it's closed via mouse or keyboard.

This creates confusion and suggests the button is in an active/focused state when it's not.

We should keep the focus on that button when accessed/closed via keyboard, but probably need to rely on :focus-visible.

[sabernhardt]

Whether you click outside the search box or press the Esc key, you return to the toolbar link you used to open the command palette. Then if you use the Tab key, the focus is still within the toolbar.

If you use the keyboard shortcut and then exit the command palette, focus returns to the element where it was before opening the palette.

[juanfra]

Right, the focus behavior itself is fine. The issue I see is related to the styling. That black/blue combination is somehow hinting that it is "active" or "selected", so seeing it on the command button after closing makes it look active when it's not.

Core trac : https://core.trac.wordpress.org/ticket/64859

---

## Test
​https://github.com/user-attachments/assets/975ff778-8db1-4899-9cfe-da26657b6129

[khushi1501]

Tested this on WordPress 7.0 Beta 5.

I was able to reproduce the issue. After opening the Command Palette from the admin bar and closing it, the button still keeps the focus style.

I also tested the patch and it fixes the issue for me.

Before applying the patch:-
​https://www.awesomescreenshot.com/video/50481760?key=73aa8cced9130288d8cb055b3e5c51d0

After applying the patch:-
​https://www.awesomescreenshot.com/video/50481877?key=b0eb954045f78aa0b418920c6b7b4dee

[joedolson]

I don't agree that this is a problem. When you close the command palette, the control to open it is focused, therefore it has the focus style. This is correct behavior.

I'm not clear what the goal is in changing this. All the current PR does is introduce an accessibility failure by creating a loss of focus.

I'm just re-iterating what @sabernhardt said above, but please clarify what the problem is here.

[juanfra]

I chose a bad title for this, and I wrote a poor description. My bad. I couldn't edit the issue after creating it.

To clarify: I'm not questioning the focus, the focus is correct.

What I'm questioning is that the focus styles make it look like it is "active" when you just closed it.

[wildworks]

The current behavior is correct from an accessibility standpoint, but I understand the confusion @juanfra is experiencing.

When the command palette is closed, it's natural that focus returns to the trigger button, but the admin bar item that has focus changes its background and text color. This style persists unless another element in the document is clicked or focused, which might give the impression that some function is enabled in the admin bar.

If we want to reduce this awkward feeling even a little, one way might be to remove the background color change from the focus style and leave only the text color change.

[juanfra]

Thanks Aki, you captured it perfectly.

The problem is not the focus, but the focus styles. They make it look selected, which feels wrong after you just closed the palette. Maybe we can update the title and description of the ticket to bring more clarity.

Usually focus states use outlines instead of a background + color combo. It wasn't super obvious before command palette existed, but now that focus returns after closing, I believe it's more evident that the styling is misleading.

[joedolson]

I can see a good argument that the focus state of adminbar items isn't clearly a "focus" state, since it doesn't match other standards of focus state across the WordPress admin.

In my opinion, the solution to fix this is to make the focus state adhere more closely to other focus states, so that the meaning of the highlight is more clear.

This is a pre-existing issue, and not specific to the command palette trigger, though the fact that the command palette is at a significant remove from the admin bar probably makes it more obvious. For any dropdown menu in the adminbar, if you tab into it, then hit esc, it will close the menu and focus the parent item, leaving the same effect.

Currently, the default focus shadow is hidden in the adminbar; perhaps we need to just reconsider that, so the behavior is more consistent with other focus.

[joedolson]

In my opinion, this is working as expected for 7.0, but there is room for improvement in the focus states in the adminbar. I'm going to milestone this for 7.1 to be addressed there.

[audrasjb]

Removing trunk version as this is not going to be shipped with WP 7.0 but in the next releases.

[afercia]

I would agree with @joedolson that focus-visible isn't the way to go. The problem with focus-visible has been well summarized by Joe on November 2024 on this Gutenberg issue: ​https://github.com/WordPress/gutenberg/issues/65088#issuecomment-2486077086

I'd just add that focus-visible makes an assumption that the user is either using a keyboard or a pointing device, which isn't true. There's no such a case of a 100% keyboard user or a 100% pointing device user. In most of the cases, users use a mix of different devices.

For example, as a low vision user, I do use both keyboard and mouse/trackpad. Still, I need a strong focus indication also when using mouse/trackpad.

That said, I understand the focus indication in the admin bar is less than ideal and potentially confusing. Personally, I would suggest to make it consistent with the one used for the admin menu: a horizontal blue outline.

The admin bar shows its age. Besides styling issues, it's unfortunate that ​it only allows to add nodes that are either a link or a clickable div, with onclick attributes and inline event handlers. That's far from modern best practices and dates to how things were made 20 years ago. Also, a href="#" is, technically, just an incomplete page fragment identifier. It's something that we should just stop using. At the very least, those usages should be deprecated and WP_Admin_Bar should allow to use buttons. Material for a new ticket.

[afercia]

I also tested the patch and it fixes the issue for me.

The patch at ​https://github.com/WordPress/wordpress-develop/pull/11263/changes introduces an intentional focus loss by using blur(), which is something that we must avoid. That would only solve the 'visual' problem but it would introduce a terrible user experience for keyboard users. When testing, please always test also with keyboard and for accessibility.

This PR introduces a significant accessibility problem, so I'm going to close it - this is not a viable path. The specific issue is still under discussion as to whether there even *is* an issue.

[joedolson]

Discussing this in the accessibility bug scrub, we're universally agreed that there is no actual issue here: the current behavior is 100% correct.

However, the fact that the admin bar uses a very subtle focus state makes it much harder to recognize what that state represents. The side menu uses that same focus state, but only in opened menus - which is a context you can only reach by having actively opened.

I'm going to close this ticket, but open a follow-up to improve the focus state to clarify user expectations.

See #65445 for follow-up.