Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MU4 Task] Accessibility improvements #12662

Open
2 tasks
abariska opened this issue Aug 3, 2022 · 2 comments
Open
2 tasks

[MU4 Task] Accessibility improvements #12662

abariska opened this issue Aug 3, 2022 · 2 comments
Assignees
Labels
accessibility Issues related to accessibility P1 Priority: High

Comments

@abariska
Copy link

abariska commented Aug 3, 2022

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
  1. 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)
  2. Additional task is to add specific MU accessibility rules
@abariska abariska added the P1 Priority: High label Aug 3, 2022
@abariska abariska self-assigned this Aug 3, 2022
@cbjeukendrup
Copy link
Contributor

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.

@shoogle
Copy link
Contributor

shoogle commented Aug 7, 2022

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.

@oktophonie oktophonie added the accessibility Issues related to accessibility label Jul 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Issues related to accessibility P1 Priority: High
Projects
Status: In the further future
Development

No branches or pull requests

4 participants