Accessibility navigation skips frames

• Jul 22, 2019 - 23:18
Reported version
3.2
Priority
P1 - High
Type
Ergonomical (UX)
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

Alt+left/right commands do not navigate to frames, so there is potentially a large amount of text in a score not ever read by the screenreader.

Working on fix.


Comments

Currently, frames are invisible to blind users. The accessibility shortcuts will not reach them, and even if you click on one directly, the screenreader does not read text within them. Thus, scores containing significant amounts of text (e.g., the handouts, homework assignments, and tests I am creating for my theory class that includes a blind student) are not accessible.

I have a fix in https://github.com/musescore/MuseScore/pull/5221, specifically in https://github.com/musescore/MuseScore/commit/df0fccdec7ba689eb3bc3f80c…. This makes the next-element and previous-element commands stop on frames rather than skipping over them, and makes the screenreader read the text with the frame.

The original commit referenced above fixes the issue in general but does not address the case of frames before the first measure or after the last - these were still skipped. We had a discussion about this on Telgram, to decide whether it made sense to modify Ctrl+Home/End behavior to select these frames rather than the first / last "measure" element as it currently does. The consensus was, keep Ctrl+Home/End as they are, but make sure Alt+Left/Right can access these. So I added a commit specifically to address that: https://github.com/musescore/MuseScore/pull/5221/commits/0c34ee08979dc8….

This works by adding a flag to firstElement() and lastElement() to control whether frames are considered or not. This will make it easier for future functions and commands to also provide either option.

Status PR created fixed

Fixed in branch master, commit ceaea1f149

_fix #292510, fix #292928: navigation and screenreader support for frames

Added code to read the text within frames in accessibleExtraInfo(),
but also fixed the navigation to check for a frame
before moving to the next/previous measure.
Because frames will generally have a track of -1,
I also needed to take advantage of the tracking of the current track from a previous commit
so that nagivation continues on the correct track after passing through a frame.
I also needed to be careful to handle the -1._

Fix version
3.3.0