1510476 - Some XUL menu item accelerators get reported twice by Windows screen readers

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P3)

Description

[James Teh [:Jamie]]

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

Comment 1

[Marco Zehe (:MarcoZ)]

Attachment: Bug 1510476 - Don't expose the keyboard accelerator in IAccessible::get_accKeyboardShortcut if a XUL menu item does not have an access key, r=Jamie

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).

Comment 2

[Pulsebot]

Pushed by [e-mail]:
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

Comment 3

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/7ce7e9407a75