Open shoogle opened 1 month ago
Advantages of making this change:
Hi! I would like to start contributing to MuseScore by tacking this issue. Is this alredy being worked on?
Hi @Leo-Cal! This is a core issue for accessibility and will set the direction for future development in this area. As such, I'd like to reserve this one for the internal team, but please feel free to tackle other issues, such as the ones on our community projects board. Thanks!
Timing of this is interesting as I just saw a request from a blind user on the MuseScoreAccessibility mailing list at groups.io to have new commands to allow more direct access to the tree, much as screen readers usually present the accessibility tree of any window or web page and allow direct access to it. This came up in a discussion about having a "next element of same type" command that would allow navigation directly from, say, one tempo marking to the next. it would be nice to design this new tree traversal scheme in a way that could easily support such commands, or even present the accessibility tree directly to screen readers.
The
EngravingItem::nextElement()
andEngravingItem::previousElement()
virtual functions define the order in which elements are visited by the Alt+Right and Alt+Left navigation shortcuts.The way these functions are currently written, they must be overridden by every
EngravingItem
subclass to determine what comes next in the sequence. However, there is no guarantee that the sequence is consistent, correct, or complete. Ideally, all interactive elements should be included, while all non-interactive elements (e.g.Page
,System
, etc.) should be excluded.These functions could be greatly simplified by rewriting them as a tree-traversal, which could look something like this:
But which tree should we traverse? There are several possible candidates for the
parent()
andchildren()
functions.EngravingObject::parent()
EngravingObject::explicitParent()
EngravingObject::children()
EngravingObject::scanParent()
EngravingObject::scanChildren()
EngravingItem::parentItem(false /*explicit*/)
EngravingItem::parentItem(true /*explicit*/)
EngravingItem::childrenItems()
AccessibleItem::accessibleParent()
AccessibleItem::accessibleChild(i)
AccessibleItem::accessibleChildCount()
We'll need to use the one that gives the closest match to the current next-element sequence.
We may still need to override
nextElement
in a few subclasses, for example, to ensure that navigation stays in the current staff rather than going up and down the segments.