Active
Project:
Drupal core
Version:
main
Component:
navigation.module
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
17 Aug 2025 at 02:48 UTC
Updated:
10 Feb 2026 at 17:19 UTC
Jump to comment: Most recent
Problem/Motivation
In #3436130: Ensure keyboard navigation works with the drawer, the MenuBar spec says for Enter / Space:
If the item is a parent menu item, opens submenu and moves focus to first item in the submenu.
For me, focus doesn't move to the first item in the submenu when the submenu opens.
This happens in both the "desktop" and "mobile" versions.
The attached video demonstrates the problem.
WCAG success criteria
Related technique
Steps to reproduce
- Enable the Navigation module.
- Log in as admin.
- Tab to an item in the Navigation menu bar that has a submenu.
- Press
EnterorSpace.
Expected
The focus moves to the first item in the submenu.
Actual
The focus stays on the parent menu item (aka, the trigger button).
Proposed resolution
- Either:
- Strictly follow the menubar pattern by making the
ENTERandSPACEkeys move focus to the first item in the submenu, OR - Decide to follow the disclosure pattern, which does not specify this requirement. This would involve changing arrow key behavior also.
- Strictly follow the menubar pattern by making the
- Update tests to confirm that it works correctly.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| navigation-focus-not-moving-to-submenu.mov | 359.53 KB | kentr |
Issue fork drupal-3541688
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
compare
Comments
Comment #2
kentr commentedFixed parent issue.
Comment #3
kentr commentedAdded WCAG SC.
Comment #4
kentr commentedMinor edit to IS.
Comment #5
catchI just tried this out and I kind of like how it works now.
I tabbed to an item with children, hit enter, and the flyout opened, but focus didn't move - as described. However, to move to the flyout, I can use the right cursor key to enter that menu. For me that felt pretty intuitive, although I don't use keyboard navigation on websites very much, and it also matches the hover behaviour. Also hitting enter again closes the flyout, which also feels intuitive.
If you hit enter, then tab, then tab takes you into the submenu, through it, then down to the next item in the top menu - which also seems good.
The current behaviour means if I wasn't sure whether an item was under structure or config or reports for example, I could continue going down the menu to see what's in the submenu, hitting enter to expand, then only going into the submenu when it's definitely where I want to end up. Instead of being taken into the submenu when that's not necessarily where I want to go. After using Drupal for 20 years I'm still not always sure where an item is, especially with contrib modules, and it seems unlikely it happens less frequently for people with less Drupal experience.
I looked at https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-naviga... and it also links to https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-...
which has:
Not sure if the disclosure navigation is sufficiently relevant to the navigation bar but that does seem like the same pattern that's currently implemented.
It looks like the last point of the issue summary is covered by #3541910: Elements in closed sidebar are focusable ?
Comment #6
catchAdding needs accessibility review tag. While this doesn't match the behaviour in https://www.w3.org/WAI/ARIA/apg/patterns/menubar/examples/menubar-naviga.... That page explicitly links to https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-... as a more common pattern, and it seems to me to be compatible with that approach. And also just from manually testing feels like a valid approach too.
Comment #8
kentr commentedYeah... Toolbar module appears to be taking the disclosure pattern route with input from @bnjmnm and @andrewmacpherson.
When I created the issue, I assumed there was a reason why the menubar pattern was chosen over the disclosure pattern for the Navigation module.
Comment #9
catch@kentr so I don't fully understand the nuances of the menubar vs. disclosure patterns - does that mean this issue is actually fine and we can close it as 'by design' or that something else needs to change?
Comment #10
kentr commented@catch I don't think it's by design.
I think an accessibility review to decide whether to strictly follow one pattern or the other would be good. My understanding is that following a pattern only partially throws users off b/c they expect certain behaviors.
The menubar spec is that the focus should move to the first item, and in #3436130-11: Ensure keyboard navigation works with the drawer @bronzehedwick said he's following that.
Also, the right-arrow key currently does open the menu and move focus to the first item, so there's inconsistency.
My interpretation of the disclosure spec is that the arrow keys don't open menus, so AFAICT the nav doesn't strictly follow the disclosure spec either.
Regarding the obscured focus, I removed it from the IS.
Comment #11
kentr commentedUpdated the proposed resolution to include the option of adopting the disclosure pattern.
Comment #13
mgiffordIn discussion with @mherchel @rkoller & @kat-shaw we decided that this is an inconsistency, but not a barrier. So not a blocker, but we should get this fixed.