Focus trap and screen reader issue when navigation menu opened in mobile view

[kymhaugen]

Using a completely vanilla install, no plugins, and the Twenty Twenty-Five theme, there are some accessibility issues present with navigation menus that contain submenus that are set to open on click.

This can be seen with a navigation menu like this:
Navigation Item 1
Navigation Item 2 (submenu)
--Submenu Item 1
--Submenu Item 2

Steps to reproduce:

1. Tab to the mobile menu button and hit Enter
2. Tab to the submenu toggle item (Navigation Item 2)
3. Hit Enter when focused on the sub menu toggle item
4. Continue to hit Tab to go through all the submenu's links - focus will remain inside this submenu and cycle through only the submenu links.

The only way to escape this submenu is to hit Escape, close the entire menu, and start over from the beginning of the navigation.

This may not be a common issue with sighted users, as they likely will not hit Enter on the submenu toggle. However, users with impaired vision who use a screenreader can easily encounter this focus trap.

The submenu toggles have aria-expanded attributes that will announce as collapsed or expanded when the user Tabs to them while using a screenreader.

For example, a site visitor using a screenreader would Tab through the menu and hear "[Submenu Toggle Text] menu, collapsed". They would hit Enter to open the menu, thus triggering the focus trap. They would Tab through all the links, reach the submenu toggle again, which will announce that it is "expanded". They would hit Enter again, it would announce as "collapsed", but when they start hitting Tab again they will still be stuck in the submenu.

This seems to be a bug with how the interactivity API handles the keydown event and cycles focus from top to bottom, even when the state of the submenu has been marked as closed.

[joedolson]

This sounds like an upstream issue in Gutenberg.

It's not a keyboard trap, strictly speaking, as it is possible to move focus away from it using only the keyboard and the use of the Esc key is a standard exit method. However, it's definitely a crappy user experience.

However, I haven't been able to reproduce this issue in a plain installation of Twenty Twenty Five following the settings you've described; there's no cycling through the submenu.

It's possible that it's something specific to a particular browser; what are you testing on?

Are you able to provide a link to a test page where you are having this experience?

[kymhaugen]

I agree; it may not be a true keyboard trap, but it is frustrating - especially for screenreader users.

I don't have a publicly available link, but this issue can be recreated in the WordPress playground with the following setup.

I made 3 new pages, and arranged them into a submenu like this.

Also set the menu to open on click.

Here is a video demo of the issue: ​https://i.imgur.com/Q0M8EKF.mp4
I tested this using the latest version of Chrome.

When I Tab to the 'Sample Dropdown' nav item and hit Enter, you can see the aria-expanded attribute change to 'true'. Then I press Tab to go through all the submenu links.

I then hit Enter on the submenu toggle again, and you can see the aria-expanded attribute go back to 'false'. Even though the submenu's state is considered closed, when I start hitting Tab again I can only access the submenu items, not the 'Sample Page' or close button.

[joedolson]

Ah ha. I see the issue. It is an upstream issue in Gutenberg, it'll be an issue in the interactivity API.

I think this can be resolved by not setting aria-expanded on the submenu parent when the submenu is already shown, but I'll explore the details and report upstream.

[joedolson]

I've reported this upstream at ​https://github.com/WordPress/gutenberg/issues/72088.

I didn't address the focus trap in that report, because I think that's really just a side-effect of other things that are wrong. The main issue here is that if the submenu is going to default to open, there shouldn't be a button with aria-expanded or any state manipulation.

There have been many requests to make submenus respect the open on click setting, and I think that if that moves forward, the focus behavior should be closely examined as part of that feature addition.

[kymhaugen]

Replying to joedolson:

I've reported this upstream at ​https://github.com/WordPress/gutenberg/issues/72088.

I didn't address the focus trap in that report, because I think that's really just a side-effect of other things that are wrong. The main issue here is that if the submenu is going to default to open, there shouldn't be a button with aria-expanded or any state manipulation.

There have been many requests to make submenus respect the open on click setting, and I think that if that moves forward, the focus behavior should be closely examined as part of that feature addition.

Thank you for helping me report it to the correct team.

+1 for the feature where the submenus can open on click in the mobile overlay, but just having that button removed when the menu can't actually be opened or closed in that state would be perfect.