Context menus not accessible
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
Menu key? can you give an example, I'm lost.
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.
https://github.com/musescore/MuseScore/pull/5453
Fixes the menu key, and NVDA works for the elements not already on the main menu. Commands that are duplicated on the context and main do not read properly, but I can live with that for now.
In reply to https://github.com/musescore… 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.
Thanks for that information! I couldn't really tell who was at fault here - us, Qt, or NVDA.
OK, here's the link https://bugreports.qt.io/browse/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?
In reply to This Qt bug mentions only 5… by dmitrio95
I only tested with the versions 5.12.5 and 5.13.1.
Could you test with 5.9.8 and maybe with 5.12.6 too?
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.
BTW, thanks @David Bailes for the legwork on this - much appreciated!
In reply to Could you test with 5.9.8… by Jojo-Schmitz
I can confirm that the bug is also present in both 5.9.8 and 5.12.6.
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._
Fixed in branch master, commit 505c0bcfb0
_Merge pull request #5453 from MarcSabatella/296416-accessible-popup
partial fix #296416: accessibility of popup menu_
The merged fix is partial, so reverting status to active.
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.
Appears to be fixed in MuseScore 4.
Automatically closed -- issue fixed for 2 weeks with no activity.