Screen Readers: No speech for add/remove element shortcut

• Jun 2, 2020 - 15:40
Reported version
3.4
Type
Ergonomical (UX)
Frequency
Once
Severity
S4 - Minor
Reproducibility
Always
Status
closed
Regression
No
Workaround
Yes
Project
MuseScore
  1. Run MuseScore with NVDA or JAWS.
  2. Enter some notes.
  3. Select a note and press a shortcut to add an element:
    • e.g. S for a slur, Shift+S for a staccato, Shift+V for an accent.
  4. Press shorcut again to remove the element:
    • Note: this doesn't work for slurs.

There is no screen reader output when you add the element in Step 3 or remove it in Step 4.

Workaround: Add the element and then press Right followed by Left to trigger speech.

Comments

• Jun 2, 2020 - 17:15

In general, most commands don't report their results, not just these. So for example, pressing N to toggle note input mode, pressing a number key to select a duration, etc. We really do need a general way to force the screen reader to read status info, that isn't tied to a change in selection.

Reply

• Jun 2, 2020 - 18:18

Well, in a sense that's already what we do - accessibiltiy info is recalculated after every command, and if it has changed, we fire an event. I am talking about cases where the accessibility info as we currently define it has not change, and am suggesting that the command processing itself should perhaps read the name of the command, at least in some cases. In my example, pressing 4 while in note input change nothing about the accessibility info as currently defined - it's still the info about the currently selected note or rest. Yet it would be good to hear that it did something "Eighth note duration selection" or whatever. On the other hand, we don't need the navigation commands to read their own names, and note input results in the new note being read, probably plenty of other exceptions.

Perhaps the data structure for each command, which currently contains the name of the command for the shortcut list, for the menu item, and for the tooltip (or something like that) should also contain a fourth bit of info for the screen reader specifically. Possibly it could default to being derived from one of the others, but really, I think it should be different grammatically - something like past tense to indicate that the job was actually performed.

Of course, aside from all this, once we know what we want read, the whole notion of "send it to the screen reader" is easier said than done!

Reply

Fix version
3.5.0