weeks[8].toString(); // Screen Reader and Accessibility Info

Hello everyone! 🙂

This week I continued my reasearch on how Qt intereacts with the screen-reader and the implementation of classes that update the status bar with the necesary informations.

1. Screen-reader

Unfortunately, here I’ve hit a dead end. I’ve succesfully implemented the QAccessibleInterface in order to provide custom accessibility info, by subclassing the QAccessibleWidget class and the QAccessibleInterface class, but I couldn’t make the screen-reader to update the informations using the QAccessible::updateAccessibility method.  I send an email on the Qt Accessibility mailing list, and asked on two forums, but no luck… In the end I’ve sent a bug report to Qt about this. For the moment I’m goind to put this aside until I here back from Qt Accessibility developers and I’m focusing on gathering all the necesary informations about the score elements so when I find out what needs to be done, everything will be in place. You can find the forum posts here[0][1] and the bug report here[2]. Also in the bug report I’ve sent my testing project so you can view there how to implement the QAccessibleInterface and if by any chance you manage to update the screen-reader feedback, please let me know. 🙂 I’ve set some debugging messages so you can see what informations Qt is querying, but it seems that either it doesn’t send them to the screen-reader, or the screen-reader ignores them.

 

2. Accessibility info

2.1 What I’ve done

I’ve implemented the apropriate subclasses of the ElementAccessibilityInfo that I’ve talked about for the next elements and they provide the respective info (for now):

– Note:

Note type, Pitch, Duration, Bar, Beat

– Cleff:

Cleff type, Bar

– Key signature (for classic key signatures)

Key signature, Key Signature type, Bar

– Barline

Barline, Barline type

Also, the information updates for consecutive selections.

2.2 Problems

No problems so far. I didn’t even had to break the encapsulation, by making the ElementAccessibilityInfo a friend class of Element as I was worried.

2.3 What else needs to be done

– Write the implementation for other element types. For now, the default behavior is to write in the status bar the element type.

– Update the status info when changing the element and the selection remains on it. For this I think I will use signals.

– Save memory space. Another advantage that I didn’t see right away is that I can keep only one ElementAccessibilityInfo object “alive”. The one that is currently in the status bar, the other ones can be deleted and reinstantiated when it is needed.

I’m very dissapointed that I’ve spent almost the whole week trying to make the screen-reader work with no luck, but hopefully the developers will be able to help me. Also, I think that by end of next week I will finish gathering the info about all the element types (at least the basic info).

Thank you! See you next week! 🙂

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