Repository navigation
UI: Show keyboard focus on disabled menu items - #85488
Merged
Merged
Conversation
🤖 PR meta 🤖🎉 PropsIf you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. Props Bot commandsYou can trigger Props Bot actions by commenting on this PR:
Updated as activity occurs, without notifying anyone named here. Add the 📦 Bundle sizeSize Change: +257 B (0%) Total Size: 8.56 MB 📦 View Changed
⚡ PerformanceShow the resultsClient side metrics exclude the server response time. front-end-block-theme
front-end-classic-theme
media-processing
media-upload
post-editor
site-editor
🏁 Flaky testsSome tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information. Backspace in
|
ciampo
marked this pull request as ready for review
October 23, 2026 22:24
mirka
approved these changes
Oct 26, 2026
| background-color: var(--wpds-color-background-interactive-neutral-weak-disabled); | ||
| color: var(--wpds-color-foreground-interactive-neutral-disabled); | ||
|
|
||
| &:focus { |
Member
There was a problem hiding this comment.
Base UI focuses a disabled item on hover as well (focusItemOnHover plus empty disabledIndices), so this matches whenever the item is highlighted, not only on keyboard focus. Can we key it off [data-highlighted] like the rest of this file? It behaves the same here and would carry over to the virtual-focus popups.
Suggested change
| &:focus { | |
| &[data-highlighted] { |
Contributor
Author
There was a problem hiding this comment.
True, switched this to [data-highlighted]
Contributor
Author
There was a problem hiding this comment.
@mirka food for thought: I'm not sure I like that we show the focus ring when hovering over a disabled menu item.
Although I'm not sure we have an easy way of showing it only for keyboard focus (that was the whole point of adopting the simpler solution that applies same active styles to hover and focus, I know 😅 )
What are your thoughts?
Member
There was a problem hiding this comment.
Maybe :focus-visible? Base UI moves focus with a plain .focus() on both hover and arrow keys, so the browser heuristic applies: pointer-only hover doesn't match, and keyboard navigation does. Once the user presses a key, hover keeps matching too, which seems fine. I checked this pattern in Chromium, Firefox, and WebKit. Since highlight and focus move together in Menu, &:focus-visible on its own should be enough here.
We can't do this in Combobox/Autocomplete, but maybe that's fine for now since this probably mostly affects Menu patterns.
Contributor
Author
There was a problem hiding this comment.
Yes, we can do this on Menu because it uses DOM focus (as opposed to Virtual Focus).
Maybe that's a better compromise, even if it introduces inconsistencies.
ciampo
force-pushed
the
codex/ui-disabled-menu-focus
branch
from
October 27, 2026 12:05
e1b6895 to
3b0ab26
Compare
ciampo
enabled auto-merge (squash)
October 27, 2026 12:13
|
There was a conflict while trying to cherry-pick the commit to the wp/7.2 branch. Please resolve the conflict manually and create a PR to the wp/7.2 branch. PRs to wp/7.2 are similar to PRs to trunk, but you should base your PR on the wp/7.2 branch instead of trunk. |
ciampo
added a commit
that referenced
this pull request
Oct 28, 2026
* Menu: Show focus on disabled UI items * Fix UI disabled menu focus changelog reference * Menu: Use highlighted state for disabled item focus rings --- Co-authored-by: mirka <0mirka00@git.wordpress.org> Co-authored-by: ciampo <mciampini@git.wordpress.org> Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Contributor
Author
Mamaduka
pushed a commit
that referenced
this pull request
Oct 28, 2026
* Menu: Show focus on disabled UI items * Fix UI disabled menu focus changelog reference * Menu: Use highlighted state for disabled item focus rings --- Co-authored-by: ciampo <mciampini@git.wordpress.org> Co-authored-by: mirka <0mirka00@git.wordpress.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #84087 and #84583. This PR targets
trunkindependently.What?
Show a focus ring when a disabled menu item receives keyboard focus.
Why?
Disabled menu items remain reachable with arrow keys, but the new popup styling leaves their current focus position invisible.
How?
Use the WPDS focus border width and stroke color through the existing outline bridges. The cue follows actual focus, while disabled items keep their neutral colors and behavior. No interaction code, public API, or global defense rule is added.
Testing Instructions
Testing Instructions for Keyboard
Verification and limits
All 60 existing Menu tests passed, along with the production build and CSS/changelog lint. CLI browser checks cover disabled focus, unavailable actions, shared item variants, WordPress global CSS, themes, and forced colors. The focus ring has at least 4.8:1 contrast against the popup background across the tested light, dark, and custom themes. No test files or test bodies were added. Actual screen readers and native Windows high-contrast mode were not tested locally.
Screenshots or screencast
Keyboard focus on disabled items in standalone Menu Default and Rich Items. Basic global CSS, light theme, 520 × 440 viewports. Captures wait for the opening animation and are cropped without changing the rendered UI.
Use of AI Tools
Implemented, reviewed, and verified with Codex. I reviewed the changes and remain responsible for them.