You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Task description
To implement access to all active elements and functions for keyboard user (without mouse at all)
Create parts for main elements of MU4 (Context menu, header (note input elements section), Inspector, score, footer (zoom, concert pitch section)
Another points to be added
There're exhausted rules for accessibility. They mostly been created for web but totally work for desktop as well.
Main task for this point is to do an accessibility audit and adapt rules to MU4 (will be done after release)
Additional task is to add specific MU accessibility rules
The text was updated successfully, but these errors were encountered:
Maybe one thing we should do is avoiding panel names like "MIDI mapping top panel" and "MIDI mapping bottom panel". I'm not a screen reader user myself, but I could imagine that for people who do rely on a screen reader, it is rather meaningless whether a panel is visually at the top or bottom of the view. Instead, I think people want to know what's inside that panel.
I must add that for many "panels", the grouping does not really make sense if you purely rely on a screen reader and don't have the visual UI.
For example, sometimes we have a panel that contains only one control. If you see the UI visually, that makes sense for the Tab order, because that control might be visually far apart from other controls. But if you use a screen reader only, it might be more convenient to have that control grouped together with other controls.
Or, sometimes, we divide controls in two groups, some controls at the top of the view, some at the bottom. Same story here.
In general we should try to avoid names that refer to positions on the screen, but it's not the end of the world to use "top panel" and "bottom panel" if there really isn't a better way to describe the options available in those panels. It does at least allow blind and sighted users to communicate together about the contents of the dialog, which wouldn't be possible if we give the panels non-obvious names that are not visible to sighted users.
Of course if nobody can think of a better name for a particular group of controls then it could be a clue that those controls don't belong together (i.e. the visual layout is wrong), but it won't always be possible to group things in the most logical way while also making efficient use of space on the screen.
Task description
To implement access to all active elements and functions for keyboard user (without mouse at all)
Main task for this point is to do an accessibility audit and adapt rules to MU4 (will be done after release)
The text was updated successfully, but these errors were encountered: