Context menus not accessible

• Nov 1, 2019 - 14:47
Reported version
3.x-dev
Priority
P1 - High
Type
Ergonomical (UX)
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

1) select an element
2) press the menu key or equivalent shorcut on the keyboard

Result: the menu that appears may or may not be relevant (seems to depend on how you selected the element, perhaps also on the position of the mosue pointer but it's definitely not only that). We need to realize the menu was accessed by keyboard rather than mouse, and access the selection instead of the mouse pointer info. I think this much would be easily fixed ScoreView::contextMenuEvent().

Worse, though, NVDA does not read the context menu. Not sure why not.

There are only a handful of things that currently require use of context menus: change instrument, properties for time signature, staff text, section break, maybe on ore two others. I know we hope to get these into the Inspector, but I'd observe that isn't actually any great win for accessibility - the context menu is more direct, really.


Comments

Some keyboards have a dedicated key to activate a popup menu. On mine it's next to the Alt key to the right of the space bar. For keybaord that lack a dedicated key, there would probably be a function key sequence to do the same, maybe Fn+Esc or whatever. Blind users would generally rely on this activate popup menus.

In reply to by Marc Sabatella

I left a comment last week which was sent to moderation, and hasn't yet appeared. This may have been because it contained a link, so I'm adding another comment without the link.
With regard to the problem with duplicated commands, this problem occurs with one of the Qt examples, and I've opened a Qt bug: QTBUG-79858.

This Qt bug mentions only 5.12.5 and 5.13.1 as affected versions, does it mean that there is no such bug in Qt 5.9.8 or was it just not tested?

It's broken in MuseScore 3.3.2 as released, that tells me the bug is in Qt 5.9.8.

To be clear: right-click an element, navigate the menu by keybaord - NVDA does not read cut, copy, paste, or any other command that is duplicated on the main menu. Well, it might the first you access it, perhaps if you haven't opened the corresponding main menu yet. But at some point it stops working.

Status PR created fixed

Fixed in branch master, commit c67620f9d9

_partial fix #296416: accessibility of popup menu

Windows defines a menu key allow context menus to be operated by keyboard.
We are triggering the popup menu in this case, but getting the wrong element:
we should be using the selection, not the element near the mouse.
This changes ScoreView::contextMenuEvent() to check for keybaord as reason,
and set the element appropriately if so.

Currently screenreader support for the context menu is still limited,
so I will update this if/when I figure that out._

Indeed, and I thought starting the commit message would prevent it from closing, but I guess not. I think once upon a time the system only looked at the initial string, so you couldn't automatically fix multiple issues in one commit either.

Anyhow, the part still not working is the screenreader feedback on duplicated items, as noted above, hopefully Qt fixes it at their end. Aside from that, this should be good now.

Fix version
4.0.0