Conversation
DesktopMenu positioned the menu but never moved focus into it, so a Tab-only keyboard user activating a menu trigger (Zoom Menu, Document Menu, Page Settings, ...) had no way to reach the menu's own items: focus stayed on the trigger and the next Tab press continued past the menu entirely. Also add the role="menu" the container was missing, matching the role="menuitem" already set on each item. Known gap left for a follow-up: navigating into a submenu does not move focus to the submenu's first item, since DesktopMenu is not remounted on that transition.
|
@etuan is attempting to deploy a commit to the CloudPDF Team on Vercel. A member of the Team first needs to authorize it. |
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.
Summary
Opening a schema-driven toolbar dropdown (Zoom Menu, Document Menu, Page Settings, the tools overflow menus, ...) positions the menu but never moves focus into it. A keyboard-only user activating the trigger has no way to reach the menu's own items: focus stays on the trigger button, and continuing to press Tab skips over the (positioned, but never focused) menu entirely.
The menu container was also missing
role="menu", even though each item already carriesrole="menuitem".Fix
In
DesktopMenu(viewers/snippet/src/ui/schema-menu.tsx):role="menu"to the container div.[role="menuitem"]:not([disabled]).anchorEl) instead of leaving it on a removed/hidden node.Steps to reproduce (before this fix)
WCAG 2.1.1 (Keyboard) — all functionality must be operable through a keyboard interface.
Known follow-up (not fixed here)
Navigating into a submenu does not move focus to the submenu's first item, since
DesktopMenuis the same component instance across that transition (onlycurrentMenuchanges) rather than being remounted. I left this out rather than half-fix it — happy to open a follow-up PR for it if useful.Testing
Manually verified per the repro steps above; no existing test suite for this package.