musescore / musescore/MuseScore

Accessibility: Tab key is disabled when an element with handles is selected

Open
#16,738 7 comments 0 reactions 2 assignees View on GitHub

@shoogle is already working on this.

Since Aug 22, 2025.

accessibility needs review UI
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
  1. Select any note (that may or may not have a slur attached).
  2. Select the slur with Alt+Right, or add a new slur with S (which also selects it).
  3. 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'.

Image Image

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.