Before the weekly update, I would like to thank Jaffar Ahmad Sidek for all his help. Jaffar is a blind musician and programmer who is helping me and Marc Sabatella when we are not sure about the details of how an aspect of accessibility should be addressed. By consulting with him we make sure that when this project is finished, MuseScore’s support for accessibility will be what visual impaired musicians expect. Thank you, Jaffar! 🙂
– In the last post I’ve said that there are 5 more objects in the tabbing order that should not be there, now there is only one and with help from Marc, we narrowed down the search place to the Palettes.
– I have fixed the problem of Return key being a global shortcut for the system break command. Remainder: This meant that other objects would not receive any event if the Return key was being pressed.
Here the problem was a bit more complicated, as David Bolton pointed out some programs choose to create a whole new state for tabbing throught the toolbar when the ALT key is pressed and we weren’t sure if it was a good idea to create a new state for MuseScore. Also the Space key is used for clicking buttons in other programs and in MuseScore it is set as shortcut for score playback. I’ve asked Jaffar about this issues and here are his answers:
a: No it is not necessary.
Q: Should tabbing start from the first menu and continue to the tool bar, or it is better like I did it to keep the Tool bar and the menu bar separated?
a: I guess this is a sort of in between answer. Most modern apps have their menus and tool bars in sync, but older apps have their menu and tool bars separately. but I think most blind users would prefer to have menus and tool bars separate.
Q: Is it ok if we keep the Space key mapped for Play/Pause score playback? I saw that this is how other programs do it too.
A: Please do. You are right. most music related apps have the space bar as the play/pause button so most blind users would find it comfortable.
Taking his advice, I’ve kept the the tool bar and the menu bar separeted and the Space key mapped as shorcut for score playback. When it comes to the Return key problem, I’ve removed it as a shortcut and now it is treated as a Key Press Event in the scoretab object. The only object who receives a Key Press Event from Qt (by default) is the object that has focus. Now, when a toolbar button has focus and the Return key is pressed, the button will be clicked(his action will be triggered), when the scoretab has focus the system break action is triggered, later if a palette option has focus it will be applied to the score, etc.
You can see the commit here  .
-The only problem that I’ve encountered here was with Qt. I needed a pointer to the main window (the parent of the scoretab object) so that I could check its state and see if matches the states when the system-break action should be triggered. Even if the constructor of the scoretab was passing the parent pointer to QWidget ( ScoreTab(QList<Score*>* sl, QWidget* parent) : QWidget(parent) ) and when calling it from the main window like this: new ScoreTab(&scoreList, this); , later on when asking for the parent pointer ( this->parent() ), the result was not what I would’ve expect.I was unable to see the changes made to the main window (like state change) from the pointer. The solution was to create my own pointer in the ScoreTab class and then everything worked perfectly.
1.3 What else needs to be done:
– Make the buttons be highlighted when Shift+Tab is pressed ( reverse tabbing)
– After talking to Marc, we’ve concluded that there should be a way to move from subwindow to subwindow (workspace, palettes, toolbar, inspector, etc), using a key sequence and the elements included in the tabbing order should be only those from the current selected subwindow. This is provided out of the box from Qt if the subwindow is undocked, but if not, all it’s objects are included in the tabbing order. Also, the solution for this should be something maintanable, something that should not be changed for every element, button, or new window that will be added to MuseScore in the future.
2.1 What I’ve done
– I began with the New Score dialog, I’ve set the tabbing order and the screen-reader feedback for the first part of it, but when I’ve moved to the other parts, I’ve noticed that there are dependencies with the clef palette and the instruments dialog and I’ve decided to take more time to carefully read the code before making any changes there.
– In the mean time I’ve set the tabbing order for the whole prefferences dialog and I’ve added the screen-reader feedback for the first tab of the dialog (general).
The following are problems from Qt:
– The screen-reader tells the text from all the QLabels when the dialog is openend
– Even if the tabbing order is set, you cannot go from button to button in a group if it is set as exclusive. You can only enter the group and move from one button to another using the arrow keys. I have to look more into accessibility guidelines and see how should I address this issue.
2.3 What else needs to be done:
– Finnish adding screen-reader support for prefferences dialog
– Finnish setting the tab order and adding screen-reader support for new score dialog
Other things worth mentioning:
I’ve looked more into the behavior of the ALT key. When this key is pressed, the first menu should be selected (in MuseScore’s case File menu). This is implemented as default behavior by Qt, so if I create a new application with a menu bar, I get the expected behavior. For some reason this doesn’t happen in MuseScore. Somewhere this behavior is overriden, but I wasn’t able yet to figure out where.
Marc Sabatella has approved the changes that I’ve made so far, so I’ve started working on the first “how to” blog post and I will post it during this week.
Thank you for taking the time to read this! 🙂