STR (with NVDA): 1. Press alt+v to open the View menu, down arrow to Sidebar, then right arrow to open it. Expected: NVDA should say "Bookmarks Ctrl+B not checked 1 of 3" Actual: NVDA says "Bookmarks Ctrl+B not checked Ctrl+B 1 of 3" This occurs because the menu item specifies an accelerator, but no access key. In the absence of an access key (Accessible::AccessKey), AccessibleWrap::get_accKeyboardShortcut falls back to the accelerator (Accessible::KeyboardShortcut). However, XULMenuitemAccessibleWrap::Name also includes the accelerator, precisely because the access key normally overrides. I think the easiest/best solution here is to override get_accKeyboardShortcut in XULMenuitemAccessibleWrap and have it only try the access key. For MSAA, it's not appropriate to return the accelerator for menu items. Originally reported as NVDA issue: https://github.com/nvaccess/nvda/issues/3057
The default implementation of get_accKeyboardShortcut falls back to using the keyboard accelerator if an access key is not available. For XUL menu items, this is not appropriate since the accelerator gets exposed as part of the accessible name already. The result was a double announcement of the keyboard accelerator on menu items that did not have an access key (underlined letter).
6 months ago
Assignee: nobody → mzehe
Status: NEW → ASSIGNED
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/7ce7e9407a75 Don't expose the keyboard accelerator in IAccessible::get_accKeyboardShortcut if a XUL menu item does not have an access key, r=Jamie
You need to log in before you can comment on or make changes to this bug.