Skip to content

Editor Menubar Focus handling fixes #3309

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

alec-mitnik
Copy link

@alec-mitnik alec-mitnik commented Jul 7, 2025

Fixes the following for the Editor Menubar:

  • Opening a menu via clicking now correctly updates the tabindex values of the menubar items (instead of the submenu items).
  • Opening a menu via hover now correctly updates the tabindex values of the menubar items (instead of updating nothing due to erroneously passing in a menu rather than an ID).
  • Opening a menu via Enter, Space, or Arrow Up/Down now updates the tabindex values of the menubar items, since it's possible for the parent menuitem to have received keyboard focus other than through a way that would have already updated the tabindex values (e.g. by pressing on it and dragging off it before releasing).

Updated Menubar Editor Preview Link

Current Menubar Editor Example


WAI Preview Link (Last built on Mon, 07 Jul 2025 10:58:18 GMT).

Fixes the following:
- Opening a menu via clicking now correctly updates the tabindex values of the menubar items (instead of the submenu items).
- Opening a menu via hover now correctly updates the tabindex values of the menubar items (instead of updating nothing due to erroneously passing in a menu rather than an ID).
- Opening a menu via Enter, Space, or Arrow Up/Down now updates the tabindex values of the menubar items, since it's possible for the parent menuitem to have received keyboard focus other than through a way that would have already updated the tabindex values (e.g. by pressing on it and dragging off it before releasing).
@alec-mitnik alec-mitnik changed the title Focus handling fixes Editor Menubar Focus handling fixes Jul 7, 2025
Copy link

@Imran-imtiaz48 Imran-imtiaz48 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This update to the MenubarEditor class shows thoughtful enhancements in keyboard navigation and focus management, especially for popup menus. You've correctly ensured that when triggering a submenu with the Enter or space key, both the parent and the child menu receive proper focus, which is crucial for accessibility and screen reader support. The addition of setFocusToFirstMenuitem and setFocusToLastMenuitem within relevant conditional blocks improves the user experience by aligning with standard navigation expectations. Also, ensuring the parent menu item is focused when toggling popups reflects good attention to detail. Overall, these changes are clean, purposeful, and contribute positively to usability and accessibility. Well done.

@css-meeting-bot
Copy link
Member

The ARIA Authoring Practices (APG) Task Force just discussed PR 3309: Proposed changes to focus handling in editor menubar.

The full IRC log of that discussion <jugglinmike> Topic: PR 3309: Proposed changes to focus handling in editor menubar
<jugglinmike> github: https://github.com//pull/3309
<jugglinmike> Matt_King: jongund was assigned to this, but he isn't present today
<jugglinmike> Matt_King: This is a set of three changes to the way that JavaScript is updating the tab index in the editor menubar
<jugglinmike> Matt_King: The first two are in response to mouse/pointer actions, and the third is in response to keyboard actions
<jugglinmike> Matt_King: I tested it from the perspective of a keyboard user, and I didn't see any changes in the behavior
<jugglinmike> Matt_King: I'm not clear whether change is expected here
<jugglinmike> Matt_King: And I wasn't able to test the mouse-related changes
<jugglinmike> arigilmore: I can try taking a look
<jugglinmike> Matt_King: That would be great, arigilmore--thank you!
<jugglinmike> Matt_King: This is all about when people are using both the mouse and the keyboard, is that right?
<jugglinmike> arigilmore: yes, when you use a mouse, clicking and hovering should change it. And also (from the keyboard) tab, enter, space, up, and down
<jugglinmike> Matt_King: I want to make sure we don't regress specific existing behavior: if you have your mouse in an area where a sub-menu would appear (if you opened it)--so it's in an empty space--and then you use the keyboard to open the menu. If the mouse happens to be sitting on the place where the submenu item would appear, then the underlying submenu item gets expanded automatically
<jugglinmike> Matt_King: This happens by accident quite often
<jugglinmike> arigilmore: Is there a related pull request?
<jugglinmike> Matt_King: We can probably find it if we search for pull requests related to "menu" and "hover"
<jugglinmike> arigilmore: maybe it's this one--
<jugglinmike> arigilmore: Oh, no, this one is from 2018. That's quite old
<jugglinmike> Matt_King: I think the one we're looking for was opened in the last year or so
<jugglinmike> Jem: I've assigned arigilmore to 3309

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants