Hello, Samadhi,
I do have some small notes that you can see below. I'm looking at this
project from the perspective of visually impaired musicians, I don't know
if the focus has changed, so will have to discuss this with Marc and
Lasconic.
2016-03-19 9:50 GMT+02:00 Samadhi Poornima <samadhipoornima...@cse.mrt.ac.lk
>:
> Sorry about the previous message. It has some formatting errors. So here I
> attach the formatted message.
>
> By considering the suggestions mentioned and the notes from Andrei here
> are the requirements of the project as I feel.
>
> 1). Make the palettes keyboard accessible
>
>
> - Make the palettes searchable by implementing a filter - A shortcut
> (something like ctrl+F9) to summon the palette filter and type the first
> couple of letters and all the palette items starting from that letter will
> be listed one below the other and the user can traverse through them by
> pressing the downwards arrow. When the required palette is found press
> enter to display.
> - Provide the ability to create regular user-assignable shortcuts –
> Add a shortcut property to the palette.
> - Make the palettes traversable by keyboard – Use Andrei’s code.
>
> In this code you also have the implementation for QAccessibleWidget for
the Palette object, here. [2] Don't forget about this part. :) It is not
enough just to provide a way to a specific part of the interface to the
user. If the screen reader doesn't report anything about it, a visually
impaired user will not know what is there.
>
> - Press a number to move to the desired element, instead of traversing
> the palette and pressing enter when the desired element is selected.
> - Each palette cell having an optional "shortcut" property that let
> you assign shortcuts to any element you wanted.
>
> 2). Enable the use of keyboard to navigate to a text element or an
> articulation or a crescendo marking. Currently Information about
> articulations, dynamic markings, lyrics, and so forth are read along with
> the notes they are attached to. So I assume that this requirement is to
> implement accessibility for those elements separately. With that
> assumption, I think we can use Implement QAccessibleInterface for those
> widgets.
>
You don't have to implement QAccessibleInterface for those widgets. The way
that the accessibility system is implemented in MuseScore is a
bit counterintuitive, because at some point libmscore might not use Qt
anymore, so what I did is to create a class called ScoreAccessibility[0],
which implements QAccessibleWidget for the ScoreView object, which gathers
the information from the selected element and creates the string which is
displayed in the status bar and exposed to the Screen Reader. To expose
those informations for each score Element there are these methods here[1],
which are overriden in derived classes. If you for example you click a text
element, or an articulation you will hear that the screen reader will tell
you about it, so that is been taken care of. The reason why you hear
information about articulations and texts and other type of elements is
because of the accessibleExtraInfo method which is implemented for notes,
rests, etc that returns all of the information for the attached elements. I
did this so the users can first read clefs, notes, rests, etc and skip the
information about the attached elements if they want to (just go to the
next element while the screen reader still talking) and once they know the
basics of the score, they can go back and see what articulation/text/etc is
attached to each note.
Basically, the way I see it (if everything works in the current build as it
did two years ago :) ), you just have to implement a way to select all the
attached elements. Once the element is selected you don't need to do
anything else, the ScoreAccessibility class will take care of the rest for
you.
I did have a plan to implement this, but never got around to. We can
discuss mine and see if Marc and Lasconic agree with it, but I think that
it is better to let you try and figure it out by yourself, you could have a
better solution. :)
> 3). Braille output- I plan on doing this by calling the FreeDots
> executable once the user enters the command to import the file to braille.
> However, this would not be the optimum solution to this since FreeDots is
> written in java.
>
>
> 4). Shortcuts to move the focus from one window to the next- Assign a
> shortcut (e.g. : cmd/ctrl+shift+tab) to summon the list of windows and the
> user can traverse through them by pressing the downwards arrow. When the
> required window is found press enter to move to it.
>
>
>
> 5). Support for other screen-readers- VoiceOver on OS X and also Orca on
> Linux
>
For this one, I did a small amount of research and I didn't find anything
conclusive about wether it is possible on VoiceOver, or not. For the Orca
I'm sure it is possible, but you might have to submit some patches to that
project as well. :)
This is my first draft. Waiting for a feedback!
>
>
> Best Regards!
>
I'm going to try to follow any discussions about this project on the
mailing list, but feel free to send me a private if I have not answered
here.
Best regards,
Andrei
[0]
https://github.com/musescore/MuseScore/blob/master/mscore/scoreaccessibility.cpp
[1]
https://github.com/musescore/MuseScore/blob/master/libmscore/element.h#L587
[2]
https://github.com/andreituicu/MuseScore/blob/accessible_palettes/mscore/palette.h#L105
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
