weeks[7].toString(); // Screen Reader feedback for score

First of all I want to appologise for being late with this weekly blog post. I just got back from camping last night and I didn’t have my laptop with me.

This week did a lot of reasearch on how to provide accessibility using the  screen reader for the score and I’ve started implementing the design for the it.

1. Reasearch

1.1 What I’ve done

– I’ve read the documentantion for the following classes: QAccessible, QAccessibleObject, QAccessibleInteface

– I’ve read some of the code from the Qt project regarding accessibility, especially for the QAccessible::updateAccessibility function

– I’ve created small programs in order to figure out what can be done and how the API works

1.2 Problems

– Unfortunatelly there is one major flaw in the idea with the status bar. The initial idea was to populate the status bar with a QLabel (or more QLabels) and make the screen reader tell the informations that are presented there. From what I can tell both by running tests and reading Qt’s code the updateAccessibility function only works when the widget for which is called has focus. Also, it is called internally by Qt when the QWidget::setFocus method is called. This means that in order for the screen reader to give the user all the informations, the status bar needs to keep the focus in that period of time. This is not an option, because the user could not would have to wait until all the information is provided and the score gets the focus again.

In order to solve this problem, I’m thinking about using the scoreview, or scoretab to place the information in their accessibleName/accessibleDescription. I need to do more tests in order to be sure.

– One thing that I don’t yet understand is how the QAccessibleObject works since a QObject that is not a QWidget cannot gain focus.

2. Design

2.1 What I’ve done

– I’ve created the ScoreAccessibility class that will manage and update all the informations using the method updateAccessibilityInfo. In the implementation of this class I used the Singleton pattern. In this way there is only one global instance for the aplication and I can access it from any object using the static method ScoreAccessibility::instance.

– As I said the ScoreAccessibility class will only manage the informations. These informations will be provided using another class, ElementAccessibilityInfo. The ElementAccessibilityInfo class will be inherited in order to get the appropriate informations for all the element types. ElementAccessibilityInfo keeps a private list with QStrings(or QLabels, or another custom class, I haven’t decided yet) and it will be populated by subclasses with the apropriate informations and this list is what the ScoreAccessibilityInfo will use.

I could’ve just added the QList to the Element class, but I think that these solution is better from a design point of view, by deferring responsability through agregation and by keeping the entropy.

2.2 Problems

– I might need to break the encapsulation by making the ElementAccessibilityInfo a friend class of Element if at some point I need to access protected, or private members

 

I’ve made this design work for the Note element and for now it works well, but I have to implement more in order to see if it holds for every element type, so things might change along the road. Also there is still that major problem of finding a place to put the informations so that the screen-reader can access them.

Because I was away for a few days I will work more this week in order to recover the lost time. 🙂

That’s all for this week!

Thank you!

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s