GNOME Bugzilla – Bug 423439
[pending] Speech context includes too much information
Last modified: 2008-07-22 19:26:58 UTC
When changing context (e.g., tab page to tab page, window to somewhere else, etc.), Orca will speak the relative information from the new component hierarchy. For example, when you tab between the "Tab" section and the "Command" section in the "Title and Command" page in the gnome-terminal profile editing dialog, Orca will speak the title of the appropriate section when you first move into it. The logic for doing this lives in speechgenerator.py:getSpeechContext, and it may be a bit too aggressive in deciding which text to include. As a result, we can end up in situations, such as in OpenOffice and Firefox, where too much repetitive information is included in the speech context. As an alternative to this, getSpeechContext should probably only include text for objects that are actually displaying text on the display. This might be as simple as making the following change in speechgenerator.py:getSpeechContext: Instead of: text = self._script.getDisplayedText(parent) do: if parent.text: text = self._script.getDisplayedText(parent) else: text = None
Created attachment 85864 [details] [review] Patch to attempt to do this across the board Here's a first pass at a patch to restrict the speech context to only those container-type things that are actually presenting text on the display. It needs a lot more exploration and testing, however, because it might be cutting out too much context. I'm not really sure, though. Note to Joanie and Mike: this also has an impact on bug 413990. You won't hear table spoken at all. If this patch seems good, though, maybe some extra work should be done in Gecko.py to force it to present information about tables that should have something spoken about them. ;-)
I'll test the patch later today. But w.r.t 413990, I think I've got the work-around layout-guess situation handled. The one sticking point was/is not speaking parent tables of the current table. For some reason, in getSpeechContent(), "bubbling up" to the outermost table after getting the relevant info from the current table sometimes caused Orca to speak things as high up in the hierarchy as the application. :-( If you solved that issue for me by not speaking tables at all, I would think that we could add special handling and maybe accomplish 413990 with less grief. So thanks!!! :-)
> You won't hear table spoken at all I still do. What am I missing?
(In reply to comment #3) > > You won't hear table spoken at all > > I still do. What am I missing? > I don't know. Maybe the question is what am I missing? If I go to your test case at http://bugzilla.gnome.org/attachment.cgi?id=83761&action=view, I don't hear table at all any more when I navigate the page.
Created attachment 85871 [details] new test case Ah, as part of my quest to create our own layout-guess for tables, my test cases have moved beyond mere mortal tables with empty summaries. ;-) ;-) ;-) You're right, given the table you referenced, I'm not hearing tables either. Here's a simple revision of that test case. When I tab from link to link, I hear table info. Do you?
Joanie and I talked about this and agreed we were looking at two separate problems. Mike also likes this patch a lot. So, I've committed it and I'm marking this bug as pending.
This looks good. OK to close.
Thanks! Closing as FIXED.
Created attachment 86516 [details] [review] Patch to better handle labels on panels and fillers The previous patch was a bit aggressive in filtering out information. In particular, there's a construct we run into where a panel or filler has two children: a label and another panel. With this construct, the label is actually labelling the containing panel. In previous versions of GTK+, we noticed this label was always the first child. It now seems to have the opportunity of being either child. So, we check for this. We have a constraint in place, however, that the label cannot be a label for anything else so as not to accidentally pick up labels we should not be picking up. As part of this patch, there are changes to the Orca glade file to get rid of the label of some panels labelling the first child in a radio button group. This may have been some other thing we ran into at one time, but it is triggering the constraint above. Now...I think I recall what we need to do with radio buttons, which is announce the radio button group when we first get into it. Let's assume we have the following construct: Blah Blah (o) radio button 1 ( ) radio button 2 With this patch, as long as Blah Blah is not a label for anything, when you first tab into the radio button group, you'll hear "Blah Blah panel radio button 1". If you then move to radio button 2, you'll just hear "radio button 2." Mike, is this the desired experience? The other place we might need to think about radio button groups is in the where am I code. Currently, it looks as though you only hear the group name if the radio button has a labelled by relation. For the above construct, this means that both radio button 1 and radion button 2 need labelled by relations pointing to the Blah Blah label. I don't think we see this in the wild, so we might need to come up with something different in where_am_I.py:_getGroupLabel. Thoughts anyone?
This seems to fix the problem I was seeing. Please commit.
Thanks, committed and re-closing.