Musescore 3.0.4 Accessibility drawback

• Mar 6, 2019 - 11:07
Reported version
3.0
Priority
P0 - Critical
Type
Functional
Frequency
Many
Severity
S1 - Blocker
Reproducibility
Always
Status
PR created
Regression
No
Workaround
Yes
Project

Hello,
I just downloaded Musescore 3.0.4, and found the accessibility has completely gone. NVDA becomes silent in the score, and I can't navigate any more. Now both accessibility and Musicxml issues beat me down from Musescore 3 to 2.

Haipeng


Comments

Status active needs info
Priority P0 - Critical

Hmm. I take it you are referring to Windows? Is it Windows 10? Other users have reported success, so I'm not sure what is going on here. Anything unusual about your configuration?

Yes, I'm using Windows 10 64-bit. NVDA doesn't read. A blind friend had told me this, and then I noticed and downloaded the latest version and duplicated the problem.

Frequency Once Many

I can reproduce this with NVDA 2018.1 on Windows 7 64-Bit and MuseScore 3.0.4 64-Bit too. You have to press the ALT key twice to get the information about the current selected note via speech and braille. But moving around the score with ArrowLeft and ArrowRight has no effects on NVDA's side. Maybe the 32-Bit version of MuseScore works with NVDA, but I haven't tested this.

For me, it does read, but a bit sporadically. Some things read right away, but others read only if I touch the mouse (don't have to actually click anything, just drag my finger along the touchpad after doing whatever). Can you verify this? If that's the issue, I should be able to investigate this myself.

I realize that. I just wanted to make sure we are experiencing the same problem. If they report no sound whatsoever, no matter what they do, even if they do what I said (use cursor key to navigate to next note then just drag finger across touchpad), then they must be experiencing a more fundamental compatibility problem than I am, so I can't help. But if they report they do in fact hear some thing but not others, and in particular they do hear the feedback after touching the mouse, then there is a possibility I can investigate and fix that much.

Status needs info PR created

PR: https://github.com/musescore/MuseScore/pull/4780

This was caused by the upgrade to Qt 5.12. I was aware of some regressions but it appear to be more widespread than I thought. I have submitted a PR reverting to 5.9 until we work out whether this is a Qt problem or if there is something we need to do differently in Qt 5.12.

NVDA users should continue using MuseScore 3.0.3 (available here) until the fix is released.

I would have guessed this, for one of the recent beta test version of Sibelius also encountered such a problem when using QT 5.12, and they had to revert to 5.9.6.

Haipeng

Should we report it to QT? I'm not a programmer, so I can't report with detailed building information, which can help the QT team to find the culprit more specifically.

I just tried Musescore 3.0.5, and the problem persists. I have to press NVDA+Numpad5 to hear the focused thing, very inconvenient. Should we report bug to QT team? otherwise we have to go the way Sibelius went, reverting to QT 5.9.7 in future versions.

Haipeng

In reply to by frfancha

@frfancha: Depending of the environment in which MuseScore is used, installing a test build isn't recommended. In that case, the only "workaround" is the downgrade option, if this is possible based on all the other fixed bugs in newer versions. Sadly, the downgrade option isn't always possible for all users. TL;DR: Install a test build on your own risk – and don't forget to fully backup your system first, if MuseScore is a critical application for you.

There are potentially multiple issues here.

The first issue is that Qt dropped support for a legacy accessibility framework called MSAA in favour of a newer one called UI Automation. This shouldn't matter because UI Automation can do everything that MSAA can (in fact it can do a lot more!), and NVDA supports both frameworks. As long as Qt implements UI Automation correctly their job is done and it is up to NVDA to use that information properly. The Qt developers reckon that that they implement UI Automation correctly for the most part, so the rest is up to NVDA.

The second issue follows on from the first. Unfortunately, NVDA does not use the information from UI Automation properly. According to the NVDA developers, this is because various other programs (i.e. non-Qt programs) are not implementing UI Automation correctly, and are actually spamming certain mouse-based text selection events so frequently that it causes NVDA to hang. The only way to prevent NVDA from hanging is to ignore these events entirely (apparently it's not possible to let them through for some programs and not others). However, this shouldn't matter because these are mouse events and people generally do not use NVDA with a mouse. Furthermore, the NVDA developers don't think this can be the cause of the problems with MuseScore because the issue reported here is not mouse-related. Still, the only way to find out for sure is to try building NVDA from source with the events no longer ignored. Even if that does solve the issue it doesn't prove it is NVDA's fault because Qt probably shouldn't be firing mouse events anyway... or maybe they should be and it is MuseScore that is using the wrong Qt function to fire events... or maybe its both! This brings us to the final issue.

Finally, it is possible that MuseScore is using Qt's accessibility features incorrectly. This could be true regardless of whether Qt or NVDA themselves have issues with UI Accessibility. Of course you could argue that, since it worked under Qt 5.9 and MSAA, therefore it can't possibly be MuseScore's fault. However, this ignores the fact that it only ever worked in NVDA,: it never worked under any other screen reader on Windows, nor under any screen reader on Linux or macOS. This makes me think that MuseScore is probably doing something wrong here as well. Unfortunately it is almost impossible work out what we should be doing in the Score View because it is a custom control, and there is a complete lack of developer tutorials for implementing accessibility in custom controls, not to mention the fact that NVDA and Qt could have issues that mask any improvements we make in MuseScore.

If Qt and NVDA can't fix this at their end and/or there are problems at our end that we can't fix properly due to lack of developer accessibility tutorials, there are some hacks that we could try without too much difficulty:

  1. Create a plug-in module for NVDA that gives it special handling for MuseScore. For example, the module could tell NVDA to watch for changes to the text written in the status bar and have it read that rather than waiting for UI Automation events.

  2. Use Qt's text-to-speech functionality to implement our own screen reader in the score view. This would give the greatest flexibility, enabling us to tell the text-to-speech engine exactly what to say and when to say it, rather than being at the mercy of a screen reader. It would allow us ensure that information like the measure number is not repeated unnecessarily when navigating between notes in the same measure, and to create shortcuts like "Repeat last announcement" or a "Where am I?" button that would cause all information about the current position to be read out. The downsides are that the voice could be very different to NVDA's, and the shortcuts would have to be different. However, It would ensure that shortcuts, and the information that is actually read out, is the same on all platforms. Reading the status bar text would be trivial, and the other aspects would make a good project for GSoC.

In reply to by shoogle

@shoogle: As far as I know, it isn't possible to access TTS Engines, which are installed as a NVDA add-on, by other applications than NVDA itself. And furthermore we shouldn't forget the braille output. For controlling the notes in a score, reading them on a braille display without TTS is much faster than listening to the TTS – even with a high speed level. So a speech output directly in MuseScore wouldn't be a good solution.

In the end creating a NVDA-appModule for MuseScore, which is part of the NVDA core, should be a better solution here. NVDA is able to recognize that "MuseScore3.exe" is running in the foreground and then loads its appModule from the "library.zip/appModules" folder.

@Anatoly-os, that's right, but we would probably only use it in the score view. We would rely on traditional screen readers for menus and dialogs because they handle those things very well, it's just the score view which is a custom interface that they can't handle.

Screen readers understand what a button or a checkbox is, but they have no idea what a treble clef is. In theory you can "teach" the screen reader to understand the score object model:

  • a chord is a list of notes
  • a measure is a list of chords
  • a staff is a list of measures
  • etc.

In this way it is possible to treat the score as a tree structure that the screen reader would understand without changing how it is rendered on screen for sighted users. Unfortunately this is very difficult to do, and with a lack of examples or tutorials most applications (including MuseScore) cheat and just try to "trick" the screen reader into reading whatever is displayed in the status bar.bHowever, screen readers are not designed to be used this way: they are supposed to give an overview of what is going on with a configurable verbosity level, which means they actually need to understand what is going on, not just be given fixed text to say to the user. If we want full control of what gets spoken then the only way is via TTS.

If anyone want's to try Qt's TTS then there is a Hello Speak Example application included with Qt. Simply open Qt Creator, go to the Welcome screen, click "Examples" and search for "speech". It only takes a couple of seconds to build.

Qt-TTS.png

@Dr. Sooom, Qt TTS does not use the NVDA speech engine; it uses the operating system's built in speech engine (so it would probably use the Narrator voice on Windows and the VoiceOver voice on macOS, but it wouldn't actually use those screen readers; just the voices). It provides full control over the speed and pitch of the voice, which we could make adjustable in MuseScore's Preferences. Overall the quality and control would be much better than relying on a screen reader.

However, you do make one very good point, which is that TTS will not provide Braille output. We might be able add that later though if we can find a C++ library that allows access to Braille terminals, though it is not clear how well that would work if the user also has a screen reader accessing the Braille terminal at the same time.

In reply to by shoogle

@shoogle: Well, and you also have to handle the different braille displays with native braille drivers (USB and Bluetooth, only some braille displays have also or only HID-support) as well. And I'm not talking about the length alone. What about the different buttons on a braille display? And what shall happen on pressing a routing key on a braille display? Furthermore I suppose that the access to the braille display is only possible via one single application at the same time. And in the end you also have to implement Liblouis too, because there are hundreds of braille tables using around the globe.
TL;DR: Extremely quite a lot of additional work, which wouldn't be necessary if you use the screenreader for speech and braille output.

As you were talking about the status bar; I guess it would be easier to fire a command to the screenreader on pressing different keys. So after pressing ArrowLeft or CTRL+ArrowRight, as a simple example, the command to read the current status bar content will be fired to the screenreader and this content would then be represented via speech and braille at the same time, but only if the focus/cursor is located anywhere on the score. If the focus is located at a menu bar entry, at an icon in the symbol lists or anywhere in the mixer, this firing command shouldn't be enforced, because that wouldn't make any sense.

Well, and how many information are displayed in the status bar in MuseScore should be configurable via the MuseScore settings. That should be easy to implement. But the fire mechanism is different between IAccessible2 and UIA. It might be better to ask NV Access directly about this, because I'm not a developer.

Just for clarification: The QT-TTS method is similar to the TTS reading functionality in the Adobe Reader. Both are useful for visual impaired users who needn't a braille display and only need speech output for a few things. But NVDA provides much more, also in PDF files, because when you open a PDF file in Adobe Reader, NVDA will render this in a virtual document, similar to a website in Firefox or Chrome. In this situation you can navigation between headlines, lists, tables, links etc. The TTS reading function in Adobe Reader itself doesn't provide these additional (quick) navigation methods.

TL;DR: The QT-TTS is just an additional solution, but absolutely no replacement for the MSAA/UIA screenreader accessibility. Both interfaces are needed for different user groups.

And to the mouse movements: The mouse tracking can be disabled in NVDA. Furthermore it shouldn't be quite difficult to implement a little delay after the mouse cursor has stopped. So in the end the element below the mouse cursor is only spoken after the mouse movements has stopped, and no longer during the mouse movements. This optional function would be new in NVDA. Shall I open a new NVDA issue for it? Would this help here a little bit, especially regarding the performance?

In reply to by Dr. Sooom

If can be a "read only mode" suitable for screenreaders, that can read the score in user language... But i think that Musescore cant do that without heavy model reworking or a specific funtionality scripted ad-hoc.
I'm wondering if a simple plugin can do that.
Is a matter of: if the cursor is over a beat, the screenreader can read the entire beat without all those actual verbosity, sending to braille display the score in their standard.