MuseScore Accessibility

MuseScore is free and open source cross-platform notation software comparable to the major commercial programs like Finale and Sibelius.  MuseScore currently has only very limited support for accessibility, with only a subset of its functionality being available from the keyboard and with only a small amount of information readable via a screenreader.  Because MuseScore is open source, it is possible for anyone with the necessary skills to go in and improve this situation.  MuseScore is built using Qt5, which provides a reasonable accessibility framework if MuseScore would only take better advantage of it.  We believe it is entirely feasible that within a short period of time, MuseScore could be made the most accessible notation program available.


The following is a list of the issues we have identified.

Full keyboard navigation of all score elements

Currently, a user can easily access notes and rests via the keyboard.  It is possible, but not easy, to access chord symbols and lyrics.  All other score elements – clefs, time signatures, key signatures, repeat signs, dynamics, etc – can be accessed only by clicking them.

Addressing this requires some knowledge of MuseScore internals – how score elements are stored – but very little expertise in Qt or accessibility techniques.  It would probably amount of a couple of hundred lines code.

Screenreader-friendly status bar listing current score element

As you navigate through the score, the status bar should display information about each element in a screenreader-friendly manner.

This is a fairly small change but it does require some knowledge of Qt and accessibility techniques.

Ability to add all score elements using keyboard alone

Some score elements can be added to the score using the keyboard alone, but most require you to click the location where you want the element added then double click a palette item, or use drag and drop from palette to score, or other non-accessible techniques.

There are at least two different ways this could be implemented.  One would be to make the current interface more keyboard friendly – that is, still use a palette but make it keyboard-controlled.  This is conceptually simple but apparently involves a relatively large internal change.  It would probably also be more work to actually use than would be ideal – the palettes can be rather large, and needing to cursor around looking for the desired symbol would get furstrating.  The other way would be to implement a new keyboard-based interface unrelated to the  current palette system.  This might be easier to implement and to use, but would probably feel somewhat “grafted on”.

Appropriate field labels and tab order for all dialogs, toolbars, etc

Currently, some dialogs appear to have almost random tab order, and text boxes do not necessarily read their labels.

This requires almost no knowledge of MuseScore internals but does require familiarity with Qt and with accessibility techniques.

Better automatic layout facilities

Currently, automatic layout of scores is possible to a degree, but many elements with collide with each other unless you manually drag them into better positioning.  This is a nuisance to sighted users, but a major obstacle to getting usable results for blind users.

This requires an intimate familiarity with MuseScore internals and realistically is probably best achievable by the core development team.  It is on their radar, but it is known to be a difficult problem.  While progress is slowly being made, it will probably be a long time before MuseScore is up to the level of Sibelius or of programs like LilyPond that specialize in automatic layout.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s