Skip to content

Navigation: Fixes aria-expanded not updating on hover submenu inside overlay#77563

Open
himanshupathak95 wants to merge 1 commit intoWordPress:trunkfrom
himanshupathak95:fix76658
Open

Navigation: Fixes aria-expanded not updating on hover submenu inside overlay#77563
himanshupathak95 wants to merge 1 commit intoWordPress:trunkfrom
himanshupathak95:fix76658

Conversation

@himanshupathak95
Copy link
Copy Markdown
Contributor

@himanshupathak95 himanshupathak95 commented Apr 22, 2026

What?

Closes #76658

When Submenu Visibility is set to Hover, the toggle button's aria-expanded attribute does not update to true when hovering over a submenu inside a Navigation Overlay. The submenu was visually shown, but aria-expanded remained false, creating a mismatch that screen readers would report as "closed" for a visible submenu.

Why?

The openMenuOnHover and closeMenuOnHover action handlers contained a guard that prevented them from running when the parent overlay was already open because overlayOpenedBy had a truthy value.

Since pointerenter directives are only added to <li> elements when submenuVisibility === 'hover', removing the guard is safe since those events can only fire inside an already-open overlay, which is exactly when the state should be updated.

How?

Removed the overlayOpenedBy guard from openMenuOnHover and closeMenuOnHover in
packages/block-library/src/navigation/view.js.

Testing Instructions

  1. Go to Appearance → Editor → Templates.
  2. Edit a template that has a navigation in an overlay (or set Overlay Menu to Always).
  3. Add a Navigation block with a Submenu item and set Submenu Visibility to Hover.
  4. Save and view the frontend.
  5. Click Open menu to open the overlay.
  6. Hover over the submenu parent item.
  7. Inspect the toggle <button>aria-expanded should now be "true" while hovered.
  8. Hover away — aria-expanded should return to "false".
  9. Confirm Click mode submenus, keyboard navigation, and Escape/focus-trap behaviour
    are unaffected.

Screenshots or screencast

Before

Screen.Recording.2026-04-22.at.21.30.43.mov

After

Screen.Recording.2026-04-22.at.21.27.40.mov

@github-actions github-actions Bot added the [Package] Block library /packages/block-library label Apr 22, 2026
@github-actions
Copy link
Copy Markdown

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

  • Required label: Any label starting with [Type].
  • Labels found: [Package] Block library.

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

@github-actions
Copy link
Copy Markdown

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @s56bouya.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: s56bouya.

Co-authored-by: himanshupathak95 <abcd95@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

[Package] Block library /packages/block-library

Projects

None yet

1 participant