A GNOME Lock Screen Accessibility Hack
By user12607856 on May 28, 2008
One of the things I like about working on Orca, is the challenge of trying to make a poorly designed application accessible to blind people.
Here's the bug. The GNOME lock screen application has started on the user's desktop. When they press any key, it invites them to type in a password. If they type in their password incorrectly, they will first see some text appearing in a label under the password text area saying "Checking...". Then this is replaced with some more text saying "Incorrect password." It then wiggles the dialog box from side to side a couple of times, then removes that text. It also clears out the password text area.
I mean, even if you are a sighted person and you'd wandered away from the screen for a few seconds, it's distinctly possible that you wouldn't have seen these messages and have any idea what happened.
For a blind person it's even worst. Nothing is spoken whilst this operation is happening (i.e. those labels don't get focus). Orca also has this feature called "flat review", where you can examine the contents of a window or a dialog component by component and see what their states are. That's not going to help here because the gnome-screensaver-dialog designers have decided that that useful information isn't needed after they've finished jiggling the dialog.
So what can you do? Well, we can write a Python script in Orca specifically for the gnome-screensaver-dialog application, to try to work around this. Every time the text caret is moved to (i.e focused in) the password text area, Orca gets an "object:state-changed:focused" event. This gets passed onto the onStateChanged callback in the Script class. In our gnome-screensaver-dialog script, we override the default behavior for that method.
Here's where the fun begins. Several other different types of "object:state-changed:..." events also arrive here, so we need to check that it's a "focused" type and the it's for a text area that has a role of "password text". Luckily there's only one of them in this application, so we don't need to get any more specific then that.
If it isn't an event we are interested in, we just pass it on to the parent class.
If it's an "object:state-changed:focused" event for the password text area, we walk back up the accessible component hierarchy for this dialog and get the parent of the parent of the parent of the object that had the event (i.e. the password text area). We know that that object has six children, and two of them are labels. Those are the ones we are interested in. So we iterate over the children and if it's a label and it has a name, then we speak the name. The name in this case will be set to "Checking..." and "Incorrect password" when those states occur.
It's hardly an exact science. It's yet another hack. This all works because we get a couple more "object:state-changed:focused" events at the right time and can extract this other information out. If the dialog is redesigned, and the hierarchy is no longer the same, then our script won't work. The real fix here would be to get the gnome-screensaver-dialog developers to redesign their code so that we didn't have to jump through hoops, but from past experience we don't always have the success we would like with this approach.