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
refactor: Improve accessibility of menus #15302
Conversation
9f9fa1f
to
5c729d2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the changes!
Thanks so much for addressing this issue! Atom users have been reporting it for at least 2 years: atom/atom#5998. Really excited to get this into a future release! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀
Release Notes Persisted
|
Thanks for these changes! Any idea which release they'll be in? |
Fixes electron#16883. This bug seems to have been introduced in the electron#15302's menu a11y refactor and is new in 5-0-x.
Fixes electron#16883. This bug seems to have been introduced in the electron#15302's menu a11y refactor and is new in 5-0-x.
Fixes electron#16883. This bug seems to have been introduced in the electron#15302's menu a11y refactor and is new in 5-0-x.
Looks like it made it into v5. See |
@ckerr did this fix left/right arrow navigation between menus? It seems still broken. |
Description of Change
There are a couple of accessibility problems related to menus that I've found:
Windows Narrator
couldn't announce any menu itemsWindows
(and I guessLinux
too) was not accessible by keyboardThe first fix was given to us by the
Chromium 69
upgrade, which allowed theWindows Narrator
to read the menus. This is because chromium'sUIAutomation
API implementation is not yet complete, and that's what the narrator uses onWindows
(but the implementation progressed from 68 to 69 to allow the menus to be read).The menu bar was not accessible because we basically didn't
focus
theView
, which in turn didn't give it keyboard events. This was done because some commands in the menu (like copy) depend on the actual content being focused, instead of the bar. I fixed this by returning the focus before the command executes. Also, focusing the menu bar was not enough, since we used a plainView
for the bar, which didn't implement any keyboard navigation of it's items. I changed the base class toAccessiblePaneView
, which implements that navigation (should fix #2504).#11587 was caused by the fact that the tray icon's context menu was spawned without a
Widget
, since it's not necessary to have aBrowserWindow
to have an icon in the tray. TheWidget
is important because that's what actually captures keyboard events, and the menus leech off their parentWidgets
for those events. I added a temporary non-visualWidget
to the menu that gets destroyed when the menu closes, which fixed the issue.Checklist
npm test
passesRelease Notes
Notes: improved tray icon context menu and menu bar accessibility