fix #299387: support for screenreaders other than NVDA #5592
Conversation
…entID wind.flutes.whistle.tin
…used in various actions relative to current score state
Qt 5.14 introduces serialisation/deserialisation for enum classes, this results in ambiguous templates between qdatastream.h and preferences.h. we specialize everything to workaround this.
+ fix one last problem in #53236
…sposition and pitches messed up
…facts Most of the MuseScore GUI uses standard Qt widgets and thus is as accessible as one can reasonably expect - especially now that the palettes have moved to QML. The main issue thing preventing other screenreaders from being viable is the scoreview. The accessibility implementation made for the screenreader several years ago works for NVDA, but a number of small details prevent other screenreaders from working. This change addresses these, allowing JAWS to work relatively normally, and Windows Narrator to also work with a manual assist (Narrator + Tab shortcut). These changes don't adversely affect NVDA, and actually improve its response somewhat, fixing some of the mysterious "split button" texts that were being read. The changes here ar small but collectivey they make a difference, oth in getting JAWS and Narrator to work better out of the box, but also in making it easier to further script JAWS to provide enhanced accessibility. I used the Microsot Accessibility Insights tool to find and debug many of these issues. - added object names and accessible text for the container objects in the main window - fixed the rect() returned by the scoreview to use global screen coordinates - gave the AccessibleScoreView a role() of StaticText rather than NoRole - allow Description as well as Value as keys to access the accessibility text() - allow Qt to determine the window() for the AccessibleScoreView - override isValid() to be sure it always returns true Tese changes allow assistive tools to better associate events with objects, and objects with windows, which is necessary in order for things to work reliably. Otherwise, there were cases where the assistive tools would be unable to find the correct object or window. Most of the changes should be completely non-controversial and harmless at worst. The change from NoRole to StaticText yielded best results after trying quite a few options. This was the only meaningful role read by Windows Narrator at all, and one of the few recognized as valid and by Accessibility Insights. There are still cases where the screenreader can get confused about the current/active object, Sometimes it can be useful to press Alt twice (transfer focus to menu bar and back). But things seem *much* better with these changes, in my testing.
MarcSabatella
force-pushed
the
299387-generic-screenreader-support
branch
from
1db5b49
to
5b4e1e8
Compare
| !(mscore->searchDialog() && mscore->searchDialog()->isAncestorOf(qApp->focusWidget())) && | ||
| !(mscore->getDrumrollEditor() && mscore->getDrumrollEditor()->isAncestorOf(qApp->focusWidget())) && | ||
| !(mscore->getPianorollEditor() && mscore->getPianorollEditor()->isAncestorOf(qApp->focusWidget()))) { | ||
| QWidget* focusWidget = qApp->focusWidget(); |
There was a problem hiding this comment.
FWIW, this change is a no-op functionally, but it is more efficient, and it aids in further debugging
mscore/musescore.cpp
Outdated
| @@ -1069,13 +1069,18 @@ MuseScore::MuseScore() | |||
| connect(ag, SIGNAL(triggered(QAction*)), SLOT(cmd(QAction*))); | |||
|
|
|||
| mainWindow = new QSplitter; | |||
| mainWindow->setObjectName("mainwindow"); | |||
| mainWindow->setAccessibleName("main window"); | |||
There was a problem hiding this comment.
are these texts the screen reader reads? If so they should be translatable (and start with upper case)
There was a problem hiding this comment.
Good point. Under normal circumstances the screen won't read most of these; they are more for the benefit of people writing JAWS scripts and as such might be better not translated. But some of them can indeed be read. I need to learn more about how the scripting works, but hopefully we can get the scripts to work from the object name alone.
Align the text on the left and make the size policy of spin box "Expanding".
MarcSabatella
added
the
work in progress
|
I've marked this as WIP, as we probably shouldn't merge it until I have a chance to work out a few more issues (and add translation to the accessible texts). I'm in touch with some JAWS scripters who will be able to guide me further - one of whom lives about 10 miles from me, so hopefully we'll be able to work together in person. I'm motivated to get as much figured out before FOSDEM as I can. |
Improve Split Staff dialogue
…-transpose-multi-instrument fix MusicXML export part of #294815 - [Musicxml im-export] - New Tran…
fix #44796: enable ptb import
[Inspector] move Tremolo Bar Properties into Inspector (fix #53236)
…oon-instrument Support for xaphoon instrument
|
... and now I'm fiddling with it again, not mergeable any more. I do hope to have things figured out well enough by mid-week though. |
Fix new Pocket-Saxes
New files bundled in AppImage: - libcupsprintersupport.so - Qt printsupport plugin - libnss3.so - a fallback for Chromebook devices - findlibs - tiny C program to check system libraries
fix #297719: AppImage: add more libraries
Update copyright
…facts Most of the MuseScore GUI uses standard Qt widgets and thus is as accessible as one can reasonably expect - especially now that the palettes have moved to QML. The main issue thing preventing other screenreaders from being viable is the scoreview. The accessibility implementation made for the screenreader several years ago works for NVDA, but a number of small details prevent other screenreaders from working. This change addresses these, allowing JAWS to work relatively normally, and Windows Narrator to also work with a manual assist (Narrator + Tab shortcut). These changes don't adversely affect NVDA, and actually improve its response somewhat, fixing some of the mysterious "split button" texts that were being read. The changes here ar small but collectivey they make a difference, oth in getting JAWS and Narrator to work better out of the box, but also in making it easier to further script JAWS to provide enhanced accessibility. I used the Microsot Accessibility Insights tool to find and debug many of these issues. - added object names and accessible text for the container objects in the main window - fixed the rect() returned by the scoreview to use global screen coordinates - gave the AccessibleScoreView a role() of StaticText rather than NoRole - allow Description as well as Value as keys to access the accessibility text() - allow Qt to determine the window() for the AccessibleScoreView - override isValid() to be sure it always returns true Tese changes allow assistive tools to better associate events with objects, and objects with windows, which is necessary in order for things to work reliably. Otherwise, there were cases where the assistive tools would be unable to find the correct object or window. Most of the changes should be completely non-controversial and harmless at worst. The change from NoRole to StaticText yielded best results after trying quite a few options. This was the only meaningful role read by Windows Narrator at all, and one of the few recognized as valid and by Accessibility Insights. There are still cases where the screenreader can get confused about the current/active object, Sometimes it can be useful to press Alt twice (transfer focus to menu bar and back). But things seem *much* better with these changes, in my testing.
…Sabatella/MuseScore into 299387-generic-screenreader-support
|
Further progress, I finally have code that enables Orca to work, with the assist of a small script that needs to be installed. I will see about getting that script included into Orca; they incldue app-specific scripts like this regularly. I will also investigate using the same approach for JAWS with Qt 5.12, then when all is sorted out I will add appropriate ifdef's to my code as needed. |
|
Apparently I mucked up the commit history while trying to push my changes for orca. Will try to sort it out. |
|
So this can get closed then? |
|
Yes. I was going to do that once the other replacement (#5627) built and passed tests successfully, but even though I'm not there yet, I'm certainly closer with that one than this. |
Resolves: https://musescore.org/en/node/299387
Most of the MuseScore GUI uses standard Qt widgets and thus is as accessible
as one can reasonably expect - especially now that the palettes have moved to QML.
The main issue thing preventing other screenreaders from being viable is the scoreview.
The accessibility implementation made for the screenreader several years ago
works for NVDA, but a number of small details prevent other screenreaders from working.
This change addresses these, allowing JAWS to work relatively normally,
and Windows Narrator to also work with a manual assist (Narrator + Tab shortcut).
These changes don't adversely affect NVDA, and actually improve its response somewhat,
fixing some of the mysterious "split button" texts that were being read.
The changes here are small but collectivey they make a difference,
both in getting JAWS and Narrator to work better out of the box,
but also in making it easier to further script JAWS to provide enhanced accessibility.
I used the Microsoft Accessibility Insights tool to find and debug many of these issues.
These changes allow assistive tools to better associate events with objects,
and objects with windows, which is necessary in order for things to work reliably.
Otherwise, there were cases where the assistive tools would be unable
to find the correct object or window.
Most of the changes should be completely non-controversial and harmless at worst.
The change from NoRole to StaticText yielded best results after trying quite a few options.
This was the only meaningful role read by Windows Narrator at all,
and one of the few recognized as valid and by Accessibility Insights.
There are still cases where the screenreader can get confused about the current/active object,
Sometimes it can be useful to press Alt twice (transfer focus to menu bar and back).
Other times using the mouse seems to kickstart things,
and other times a restart of MuseScore seems the only recourse.
But things seem much better with these changes, in my testing.
I know of no way to create automated tests for this.