GNOME Bugzilla – Bug 754249
Use tooltip_text to set default accessible name on GtkToolButtons
Last modified: 2018-05-02 16:44:16 UTC
If no accessible name is set on a GtkButton, the tooltip text is used instead. But GtkToolButtons with a tooltip are completely inaccessible unless an accessible name is set manually. If we change this to match the behavior of GtkButton, many toolbars will become accessible for free. This patch: * Might be evil? (Ben?) * Maybe belongs in GtkToolItem instead? * Works
Created attachment 310200 [details] [review] GtkToolButton: set tooltip as fallback accessible name If no accessible name is set when tooltip text is added, set the tooltip text as the accessible name. This will immediately improve accessibility of all GtkToolButtons where an accessible name is not explicitly set.
Created attachment 310201 [details] [review] GtkToolButton: set tooltip as fallback accessible name If no accessible name is set when tooltip text is added, set the tooltip text as the accessible name. This will immediately improve accessibility of all GtkToolButtons where an accessible name is not explicitly set.
Isn't the tooltip used for the description? Also, toolbuttons have a label. Shouldn't we better use that? Or is that label not used anymore in modern code?
(In reply to Benjamin Otte (Company) from comment #3) > Isn't the tooltip used for the description? I don't think so... regardless, Orca does not read it, currently. > Also, toolbuttons have a label. Shouldn't we better use that? Or is that > label not used anymore in modern code? It would probably be good to prefer the label to the tooltip if a label exists... but at least in my case, the toolbuttons do not have labels.
(In reply to Benjamin Otte (Company) from comment #3) > Isn't the tooltip used for the description? Yes it is. But the GtkToolButton is exposed at an ATK_ROLE_PANEL with one child of ATK_ROLE_PUSH_BUTTON. Orca presents the button; but the panel parent gets the description from the tooltip.
(In reply to Michael Catanzaro from comment #4) > It would probably be good to prefer the label to the tooltip if a label > exists... but at least in my case, the toolbuttons do not have labels. I guess the right behavior would be to use the text of the label if set, and the text of the tooltip otherwise.
Comment on attachment 310201 [details] [review] GtkToolButton: set tooltip as fallback accessible name Chatted with Joanie and she agrees. This patch shows how to set the accessible name from tooltip text. An updated patch should consider the label first, and only use the tooltip text if there is no label.
*** Bug 748924 has been marked as a duplicate of this bug. ***
Created attachment 349205 [details] [review] GtkToolButton: set tooltip as fallback accessible name Hello, I tried to updated the patch as suggested, is it correct to also consider the label widget or is this wrong? (I did not test it yet, sorry - have to compile again in another way later)
(In reply to Kai Lüke from comment #9) > Created attachment 349205 [details] [review] [review] > GtkToolButton: set tooltip as fallback accessible name > > Hello, > I tried to updated the patch as suggested, is it correct to also consider > the label widget Yes, it's correct to consider the label widget. > or is this wrong? > > (I did not test it yet, sorry - have to compile again in another way later) The patch is indeed wrong because the goal is to use the label text to set the accessible name if there is a label, and your patch doesn't do that, it only ever uses the tooltip text.
(Thanks for taking the initiative to fix this properly in GTK+!)
I did some tests to find out about the (unpatched) behavior of GTK 3.22 with Orca. As far as I can see the tooltip is announced instead of the label (widget) if can_focus=True. But label (widget) is announced if can_focus=False. Both cases are without accessible name set. Is this desired and should remain? (It would mean that just the tooltip text needs be copied as fallback only if can_focus=False and there is no label.) Or should regardless of the can_focus value always either a label or otherwise the tooltip text be copied to the accessible name? (This would change the announcement from tooltip text to label text if can_focus=True.) By the way, should we be concerned that after an accessible name is set from these properties it can't be updated anymore because the origin of the value is unknown?
(In reply to Kai Lüke from comment #12) > I did some tests to find out about the (unpatched) behavior of GTK 3.22 with > Orca. > > As far as I can see the tooltip is announced instead of the label (widget) > if can_focus=True. > But label (widget) is announced if can_focus=False. > Both cases are without accessible name set. > Is this desired and should remain? > (It would mean that just the tooltip text needs be copied as fallback only > if can_focus=False and there is no label.) I'm... not sure, but I don't think that seems desirable. Maybe I am completely wrong. Joanie, do you have an opinion on this? > Or should regardless of the can_focus value always either a label or > otherwise the tooltip text be copied to the accessible name? > (This would change the announcement from tooltip text to label text if > can_focus=True.) This is the behavior I would expect instead. > By the way, should we be concerned that after an accessible name is set from > these properties it can't be updated anymore because the origin of the value > is unknown? I'm not very familiar with accessibility and I don't understand what this means.
Created attachment 351381 [details] [review] GtkToolButton: accessible name from tooltip With updating the accessible name I mean that once it's set from the tooltip and the tooltip changes then it won't be updated because the condition !atk_object_get_name (accessible) is false. Also there is no way to later decide where the value comes from. So I tried introducting a flag accessible_name_derived to distinguish between accessible_name coming from tooltip copying an original accessible_name (set to false again for something like notify::accessible-name). But soon realized that the whole check for the current accessible_name can be left out anyway since gtk_tool_button_set_label() will also overwrite any value. So I've adopted this simpler behavior in the attached patch. Otherwise gtk_tool_button_set_label() needs to be patched in order to keep original values of accessible_name. In general I think that if a custom accessible_name should be supported which is not coming from a label(widget)/tooltip then we need to create gtk/a11y/gtktoolbuttonaccessible.{c,h} and put the proper logic into gtk_tool_button_accessible_get_name there instead of trying to keep precedence when copying the values. Yet I'm not sure how to create the file - which functions does it need to implement and can it be based on gtk/a11y/gtkbuttonaccessible or must it be derived from gtk/a11y/gtkwidgetaccessible? Regards, Kai
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/571.