musescore / musescore/MuseScore
Accessibility: Tab key is disabled when an element with handles is selected
@shoogle is already working on this.
Since Aug 22, 2025.
- Dominant language
- C++
- Stars
- 15.1k
- Forks
- 3.3k
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 91
Description
Issue type
UI bug
Bug description
When navigating via keyboard to an element with grab handles (e.g. frames, lines, barlines), MuseScore automatically enters "Edit mode", which prevents Tab and Shift+Tab from navigating to other panels or toolbars.
Also, while in Edit mode, there's no useful feedback from the screen reader to indicate what's happening, so navigation appears stuck to blind users.
Steps to reproduce
- Select any note (that may or may not have a slur attached).
- Select the slur with
Alt+Right, or add a new slur withS(which also selects it). - Press Tab.
Expected result:
- Keyboard focus moves to the status bar (and the screen reader says so).
Actual result:
- Focus cycles between grab handles used to adjust the start, end, and shape of the slur.
- If there's a screen reader running, it says nothing, or only unhelpful words like 'blank'.
Screenshots/Screen recordings
No response
MuseScore Version
OS: Debian GNU/Linux 11 (bullseye), Arch.: x86_64, MuseScore version (64-bit): 4.0.2-230690504, revision: github-musescore-musescore-dbe7c6d
Regression
No.
Operating system
Debian 11
Additional context
To be honest, now that we have F6 to move through the UI, maybe this is no longer a concern. But it would be good to get some usability / accessibility testing on this, and have a clear and consistent story going forward.
Also, I will again note that while entering chord symbols, Tab always used to function to move to next measure, but this now navigates the UI instead. Supposedly this was because we had adopted a policy of Tab always navigating the UI. All things considered, I still think I'd prefer we simply allow Tab to be used to move to next measure for chord symbols as in MU3, and then not worry about changing the behavior Tab for elements with handles. But if we're going to hold to the model that Tab must always navigate the UI despite the existence of F6, then we do need to make it work more consistently, and that means for frames, barlines, lines, etc.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.