Excess speech feedback when using JAWS screen reader

Your idea

The speech feedback using JAWS is excessive, redundant, and makes workflow inefficient

Problem to be solved

Is there a way of controlling how much speech feedback the user receives when using a screen reader? I didn't see any setting under Preferences for controlling this.

As an example, here is the speech feedback I got from JAWS when arrowing to a particular measure and beat in my project:

"Measure 10, Measure 10
Segment, Measure 10 Beat 3
Chord, Measure 10 Beat 3
Note A flat 4 Quarter, , Measure 10 Beat 3"

There is obviously a lot of redundant feedback here. The speech feedback not only takes too long to listen to if one wants to work efficiently, but it also masks the key information that I would like to hear, i.e., the note and duration.

There is also useless information in the feedback. For example, there is no variable "segment" information. Also, there are no "chords" just single "notes". So perhaps those announcements can be removed.

Another thought to help minimize the amount of speech while still providing the user with key information is to only speak items that have changed since the last navigation command was given. For example, If I arrow to measure one beat 1 and then arrow to beat 2 of the same measure, I am obviously in measure 1 and don't need to hear "mesure 1 beat 1" again since "beat 2" would be sufficient.

Perhaps there could be some settings added to the preferences (maybe under an "Accessibility" category?) in which each user could specify how much feedback is desired. This might include what types of items are spoken, whether information that has not changed is spoken or not, etc.

When the braille support becomes more robust for JAWS, I would also hope that the same philosophy can be applied to what is displayed in braille since most braille displays have limited real estate to show braille (usually 40 characters for most displays and no more than 80 for the high end displays). Additionally, using abbreviations like "m:' and "B:" for measure and beat would save a lot of braille real estate to ensure that information can fit on the braille display.

--Pete

Prior art

No response

Additional context

No response

No files, tests, or implementation entry points are named. Start by locating the JAWS speech-feedback and accessibility navigation code, then determine whether the issue's requested controls or reduced redundant announcements can be specified consistently. Done should include an agreed feedback behavior and coverage for the relevant navigation cases.