GNOME Bugzilla – Bug 683748
Provide widget names for AT-SPI and Dogtail, namely for the GtkApplication app menu
Last modified: 2021-07-05 14:20:01 UTC
I use dogtail to ensure proper testing of the Pitivi user interface. According to what I see with the "sniff" tool, the accessibility technologies do not see the appmenus that are related to a given application. For example, there is no menu entry or widget for gnome-contacts or gnome-documents.
(In reply to comment #0) > I use dogtail to ensure proper testing of the Pitivi user interface. > According to what I see with the "sniff" tool, the accessibility technologies > do not see the appmenus that are related to a given application. AFAIK, those appmenus are not being displayed by the applications itself. From here: http://developer.gnome.org/gtk3/3.3/GtkApplication.html "GTK+ makes these menus appear as expected, depending on the platform the application is running on. " In the case of GNOME3 (the platform specified at the bug description), those menus are being displayed by GNOME Shell. Several years have passed since the last time that I tried dogtails tools (in fact I thought that dogtail was not compatible with the current pyatspi2 stack, is that assumption false?), but those appmenus works properly with Orca (I have just tested). > For example, > there is no menu entry or widget for gnome-contacts or gnome-documents. Have you tried looking under GNOME Shell instead of the applications themselves? Meanwhile closing as INVALID. PS: other accessibility debug tool to review the accessible hierarchy of gtk applications is accerciser, just in case you want to test using other apps.
Moving to gnome-shell. It seems that it is quite a mess: there is a huge pile of stuff seen in "sniff", and very few widgets actually have a "name" there. So, gnome shell should have its app menu widget named and easily spottable (I couldn't find it with accerciser either), and other important widgets should be named too.
Created attachment 223996 [details] Dump of the accessibility hierarchy for gnome-shell This file contains a text file with the dump of all the accessibility object hierarchy. At that moment the active application was UXTerm. At the AppMenu it only have the Quit entry. If you take a look to that part: -- Role='label' Name='UXTerm' Parent Name='' -- Role='text' Name='' Parent Name='UXTerm' -- Role='panel' Name='' Parent Name='' -- Role='panel' Name='' Parent Name='' -- Role='panel' Name='' Parent Name='' -- Role='panel' Name='' Parent Name='' -- Role='panel' Name='' Parent Name='' -- Role='panel' Name='' Parent Name='' -- Role='menu item' Name='' Parent Name='' -- Role='label' Name='Quit' Parent Name='' -- Role='text' Name='' Parent Name='Quit' So you have a item with the name UXTerm, and then a item with the name Quit
(In reply to comment #2) > Moving to gnome-shell. It seems that it is quite a mess: there is a huge pile > of stuff seen in "sniff", and very few widgets actually have a "name" there. In most of the cases, items doesn't have a name directly, but a relation are created between the item and a label: http://git.gnome.org/browse/gnome-shell/tree/js/ui/popupMenu.js#n392 Why? Because having the menu item, and a label with the proper text, it is easier/better to just point that the label is labelling the menu item. Other option would be start to move the text from the label to the accessible name. More info about relations: http://developer.gnome.org/atk/stable/AtkRelation.html#AtkRelationType > So, gnome shell should have its app menu widget named and easily spottable (I > couldn't find it with accerciser either), and other important widgets should be > named too. If there is a relation, you can find it with accerciser: select the element -> Interface Viewer -> there are a Relations Summarizing, there is a way to get a proper name/label for the menu items (FWIW, it was added on bug 667376). As I said on comment 1, if you interact with Orca, it exposes the name of the menu item, so the accessibility support on GNOME Shell is providing enough information. If sniff is not able to expose that name, it is in my opinion a problem with sniff. AFAIK, ldtp [1] also uses the label relation when the accessible doesn't have explicitly set the property accessible-name. I'm not a owner/reviewer of gnome-shell, but IMHO, this bug should be closed as INVALID, as those menu items (the related with the AppMenu) has a proper way to get the name. [1] http://ldtp.freedesktop.org/wiki
(In reply to comment #4) > Other option would be start to move the text from the label to the accessible name. Something that it is a bad idea, IMHO.
Sniff does work with the relations between objects and labels too. However that's not the point here really. I am planning to make a couple of methods into dogtail to help work with these new GTK3 super menus. Dogtail will be able to give you the menu node for an app or window object no matter if the menu comes from gnome-shell or the app itself when not running gnome-shell. Should be up in 0.8.2
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.