GNOME Bugzilla – Bug 677347
The accessible name of the 'Lock'/'Unlock' button is always 'Lock'
Last modified: 2012-07-09 01:13:38 UTC
Created attachment 215496 [details] event listener Steps to reproduce: 1. Launch the attached listener in a terminal window. 2. Interact with the 'Lock'/'Unlock' button (e.g. in User Accounts or in Date and Time): Give it focus, press it, cause its displayed label to change, etc. Expected results: The accessible name would reflect the on-screen text. Actual results: The accessible name is always 'Lock'. Furthermore, there do not seem to be any property-change events which might signal to an AT (or to AT-SPI2) that the name has changed. Impact: An AT (e.g. Orca) presenting the button always presents it as the 'Lock' button. An AT making it possible to interact with widgets via speech recognition + AT-SPI2 will not be able to support clicking on the 'Unlock' button.
thats a gtk widget
Not an easy fix for this. Button accessibles are defined to not have any children (who did that?) and to use the text of the first label found with a depth-first search (why?) in its children as the name. One could change this to look for a visible label only, but that would not get you change notifications. In general, this approach does not allow change notifications without a lot of redesign inside GTK. Now, one could special-case this for GtkLockButton, but that would require writing a new accessible. And because GtkLockButton is a regular GtkButton (why?) it seems to allow adding custom child widgets (should it?) So I'm not sure why all this stuff behaves that way at all and what the proper fix is.
(In reply to comment #2) > Not an easy fix for this. > > Button accessibles are defined to not have any children (who did that?) :) > children as the name. One could change this to look for a visible label only, > but that would not get you change notifications. Personally, I'm less concerned about the notifications. I was merely pointing that out since I happened to notice it. The must-have results for me is what I identified in the opening report as "expected." > In general, this approach does > not allow change notifications without a lot of redesign inside GTK. How much work would it take to cause the accessible name to reflect the displayed text without a change notification?
Here is the minimal patch that makes get_name return "Unlock" when appropriate. As Benjamin said, no change notification. And it seems that orca is caching the value ? At least, it keeps saying Unlock, after I unlocked the button, which changed the label to "Lock". diff --git a/gtk/a11y/gtkbuttonaccessible.c b/gtk/a11y/gtkbuttonaccessible.c index d0b9d16..d9fab26 100644 --- a/gtk/a11y/gtkbuttonaccessible.c +++ b/gtk/a11y/gtkbuttonaccessible.c @@ -99,7 +99,8 @@ find_label_child (GtkContainer *container) child = NULL; for (tmp_list = children; tmp_list != NULL; tmp_list = tmp_list->next) { - if (GTK_IS_LABEL (tmp_list->data)) + if (GTK_IS_LABEL (tmp_list->data) && + gtk_widget_get_visible (GTK_WIDGET (tmp_list->data))) { child = GTK_WIDGET (tmp_list->data); break;
(In reply to comment #4) > Here is the minimal patch that makes get_name return "Unlock" when appropriate. > As Benjamin said, no change notification. And it seems that orca is caching the > value ? Or AT-SPI2 is caching it on Orca's behalf. Orca does very little caching of its own, and what little it does do it dumps extremely often. Nonetheless, I'll take a look soon. In the meantime, I assume that when you use the listener from the opening report, the correct name is printed each time focus is given to the button?
I've pushed a set of patches to master that fixes this. Or rather: The supplied test works now. I tested it against tests/testlockbutton.