Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Navigation block: decouple ESC key JavaScript action from focus trap #63033

Open
webmandesign opened this issue Jul 1, 2024 · 0 comments
Open
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended

Comments

@webmandesign
Copy link
Contributor

Description

First, I'm not sure whether this is a bug or a feature request.

During accessibility review of my theme there are interesting points regarding the focus trap issue in mobile menu (the overlay menu of Navigation block). (Check the "Finding 2" and "Finding 3" for more info.)

Unlike Twenty Twenty-Four theme, my Zooey theme displays mobile submenus (the submenus in overlay menu mode of Navigation block) collapsed. I decided to do so as the functionality is still enabled in the Navigation block, and it is just a matter of CSS styles to re-apply it for overlay menus.

However, this produces an accessibility issue of focus trap when submenu is expanded in overlay menu.

From my debugging it seems to be triggered by JavaScript handleMenuKeydown() action applied both on overlay menu wrapper and on all submenu containers.

If I understand correctly, the handleMenuKeydown() action is applied on submenu containers only for enabling ESC key action on non-overlay menus. It was never intended to create a focus trap on submenus when overlay menu is opened.

Both ESC key action and focus trap are meant only for overlay/mobile menu container.

To prevent similar issues and allow theme authors to decide the submenu actions themselves if needed, please decouple the ESC key action from focus trap. Now they are both triggered by single JavaScript handleMenuKeydown() action, which makes it impossible for me to control the submenu behavior so it can pass the accessibility review.

I suggest decoupling the JavaScript action into 2 separate actions of handleEscapeKey() and handleFocusTrap(), and trigger these actions on elements with data-wp-on--keydown-esc and data-wp-on--keydown-tab attributes, respectively.

The current faulty behavior (based on description of the accessibility review) can be previewed at theme's PlayGround instance.

It would be probably a good idea to provide theme authors more information about Navigation block accessibility actions as debugging this issue was a bit tedious task for me.

Thank you for consideration!

Step-by-step reproduction instructions

Based on description of the accessibility review, please check the behavior of expanded submenu focus trap in opened overlay menu of Navigation block in theme's PlayGround instance.

Use keyboard to open and close overlay/mobile menu and its submenus.

Once submenu is expanded, test the SHIFT + TAB key to see it does not work as focus trap JavaScript action recalculates first and last focusable element and applies focus trap incorrectly.

Screenshots, screen recording, code snippet

You can check videos provided at theme accessibility review comment.

Environment info

  • WordPress 6.5.5
  • Zooey theme 1.1.2
  • Gutenberg 18.6.1

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

@webmandesign webmandesign added the [Type] Bug An existing feature does not function as intended label Jul 1, 2024
@skorasaurus skorasaurus added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Jul 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

2 participants