Screenreader fails to read accidentals in key signatures and notes without explicit accidental

• Aug 9, 2019 - 15:52
Reported version
3.2
Priority
P1 - High
Type
Ergonomical (UX)
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
PR created
Regression
No
Workaround
No
Project

1) score with one staff in key of Eb major
2) add Eb note to score
3) enable NVDA
4) select the note or the key signature

Result: both are read as "E" rather than "E flat"

The issue with the note is due to https://github.com/musescore/MuseScore/pull/4492/files#diff-0efdea4cfe3…. This was broken in 2.3.2 as well and this line of code still said "flat", so apparently something else was different then. But changing it back to "flat" does solve it in current master.

The issue with the key signature is due to the keyNames array in keysig.cpp: https://github.com/musescore/MuseScore/tree/master/libmscore#L26. This never actually worked that can tell. It doesn't read in 2.3.2, and changing it to flat here would affect the palette tooltip as well.

Perhaps the best solution is to train the screenreader to read the accidentals, then these and any other similar cases would be solved together. We could also avoid changes to this core code by doing a substitution in any relevant accessibleInfo() or screenReaderInfo() functions.


Comments

Here are some ideas. Read the status bar which always displays the proper note name or read the variable used to create the Eb (in your example) rather than the one used to display the note for the status bar.

Thanks for the suggestion! So you know, the screenreader does normally use the status bar info as a starting point (or in some cases, the same starting point is used to generate both. But that's exactly the problem here: the status bar has the Unicode flat sign character, that's what the screenreader info has too, but it just doesn't know how to pronounce it, so it says nothing. I've found a good place to translate these Unicode characters to English for the screenreader that catches most places, but the key signature selector in the New Score Wizard doesn't go through that path so I need to deal with that separately.

The PR fixes the issue by substituting (translated) English word for the Unicode characters using a new static function "makeReadable()" I added to ScoreAccessibility. This is used in the code to construct the readable version of the status bar for the case of notes like F# in the key of G, but also in the code for traversing the palette scroll area used in both the create new score wizard and when navigating palette search results, so that key signatures themselves also get corrected, The relevant code is in https://github.com/musescore/MuseScore/pull/5221/commits/ca298da3035403….

BTW, currently, the palette search results can be navigated by keyboard, and this change corrects the screenreader info to include the name of the accidental, but unfortunately the screenreader info never gets read. I added a TODO to the code to mark where this would need to get fixed, then also added another commit to actually fix it: https://github.com/musescore/MuseScore/pull/5221/commits/a3104295a549ba….

I am well aware that eventually the palettes will be replaced with a more accessible implementation, but meanwhile, I need this working within the next few days for my work teaching a course with a blind student. I can revert the latter change if necessary once the new palettes are ready to be merged, if my change here creates a conflict.