GNOME Bugzilla – Bug 486912
Labels do not support accessible text very well
Last modified: 2008-07-22 19:33:18 UTC
Steps to reproduce: 1) Run the "Dialog and message boxes" demo of gtk-demo 2) Bring up the "Message Dialog" window. 3) Tab to the "This message box has been popped up the following number of times:" label. Several things are broken: * Selection information isn't presented properly. This includes when new text is selected and unselected * Cursor/caret position isn't shown properly in braille (it always thinks it is at the beginning of the text) * Characters are not spoken as you arrow over them
Where Am I doesn't present the text selection information, either. :-( For all intents and purposes, this probably should be treated like an uneditable text entry area that was prepopulated with text.
See also test/keystrokes/gtk-demo/role_label.py.
Just tried this with the latest version of Orca from SVN trunk: > Several things are broken: > > * Selection information isn't presented properly. This includes when new > text is selected and unselected When I initially Tab to this label, I get: SPEECH OUTPUT: '' SPEECH OUTPUT: 'This message box has been popped up the following number of times: selected label' If I then press a Left or Right arrow key to unselect the text, nothing is spoken. Mike/Will, what should be spoken for those two cases? > * Cursor/caret position isn't shown properly in braille (it always thinks it > is at the beginning of the text) Agreed. I'll look at this next. > * Characters are not spoken as you arrow over them This is working just fine for me.
Created attachment 99727 [details] [review] Revision #1 The attached patch seems to correctly handle setting the cursor/caret position correctly for the braille display. The _getBrailleRegionsForLabel() method now has identical code to the _getBrailleRegionsForText() method. A better fix might just be to do: self.brailleGenerators[pyatspi.ROLE_LABEL] = \ self._getBrailleRegionsForText In testing this, I found another related bug. If you Shift-Left or Shift-Right along the label, it doesn't speak or braille anything. If this was a text object, we would be getting "object:text-caret-moved" events and handling it there. For the label, we are just getting "object:text-selection-changed" events, and that is currently a self.noOp in default.py. So the question here is, should we adjust default.py to be something like: listeners["object:text-selection-changed"] = \ self.onTextSelectionChanged and then create a new onTextSelectionChanged() that checks if this is a label and does something similar to what's done in onCaretMoved() for text objects, or should we file a bug against atk/gail and get them to send us an "object:text-caret-moved" event for this label action? Or both? Will, what would you like me to do for this case?
> onCaretMoved() for text objects, or should we file a bug against > atk/gail and get them to send us an "object:text-caret-moved" > event for this label action? Or both? > > Will, what would you like me to do for this case? Rich and I discussed this on the phone -- it looks like a bug in the label code. A bug that the text-caret-moved events are not being fired should be logged. Thanks Rich!
I've open bug #500679 on the Shift-Left/Shift-Right problem.
We discussed this bug in the Orca team meeting this afternoon. Mike is fine with the way that the label's selected text is currently spoken (concern #1 in comment #3). We've also filed bug #500679, to get "object:text-caret-moved" events, so that we can treat labels like text objects. As that wasn't a direct concern of this bug and the other problems have been addressed, I've just gone ahead and committed the patch attached to this bug, and have put the bug into a "[pending]" state. Thanks.
looks good
Thanks. Closing as FIXED.
Reminder to self: still need to adjust test/keystrokes/gtk-demo/role_label.py