GNOME Bugzilla – Bug 734912
Nodes to be named correctly for a11y
Last modified: 2014-09-29 17:13:22 UTC
The UI nodes of Evince are (as of now) not a11y friendly. For instance in the UI hierarchy dump : [application | evince] [frame | ] [filler | ] [tool bar | ] [panel | ] [filler | ] [push button | ] [action | click | ] [push button | ] [action | click | ] [panel | ] [filler | ] [text | page-label-entry] [action | activate | ] [text | ] [action | activate | ] The nodes under "tool bar" have both the same "roleName" - "panel". Since Dogtail relies majorly on the "rolename" or "name"/"description" if the roleName for nodes is the same, it is tough to write tests for the same.
As a suggestion we will need to have the buttons named or added with a description. This is also highly recommended to help the impaired people use the application using Orca etc.
Hi ! I'm using GNOME 3.12 and all the buttons are named and I lot of work are in progress for Evince 3.14. It it is expected that PDF documents will be largely accessible. You must be using an old version of Evince. There wasn't too much work in making the Evince UI accessible because Evince didn't have accessible support for any document format. Since GNOME 3.12, Evince has some preliminary accessibility support for PDF so the accessibility of the Evince UI has received some attention that it is being improved for GNOME 3.14.
Shivani, we are in UI freeze (or will be) starting today, so if you get evince 3.13.90 you can get a UI of evince that won't change in at least one release. Anyways, how can I get this hierarchy myself in order to test with latest evince?
Jose: Sorry about a late follow up, I have been getting this dump with the help of ipython , importing dogtail libraries in the same can give you app.dump() , I have explained the procedure in more detail here -> http://shivanipoddar.wordpress.com/2014/08/18/navigating-the-ui-by-ipython/ You can also ping me on #qa to catch up on the same. Hope that answered your query :)
> The UI nodes of Evince are (as of now) not a11y friendly. > For instance in the UI hierarchy dump : > > [application | evince] > [frame | ] > [filler | ] > [tool bar | ] > [panel | ] > [filler | ] > [push button | ] > [action | click | ] > [push button | ] > [action | click | ] > [panel | ] > [filler | ] > [text | page-label-entry] > [action | activate | ] > [text | ] > [action | activate | ] > > The nodes under "tool bar" have both the same "roleName" - "panel". Since > Dogtail relies majorly on the "rolename" or "name"/"description" if the > roleName for nodes is the same, it is tough to write tests for the same. This sounds like an odd requirement to me. It is really usual that the children of a given node have all the same role. For example, a common tool bar (not this case) could have all their direct children with the role button. Panel is just a generic container, I don't see why this case should be different. (In reply to comment #1) > As a suggestion we will need to have the buttons named or added with a > description. This is also highly recommended to help the impaired people use > the application using Orca etc. It would be more useful for evince developers if you point which buttons are the ones that miss a name. After a quick test with Orca, the "View options" and "File options" buttons, top right, lacks an accessible name. Not sure if those are the ones listed on the UI hierarchy. The surpringsly thing is that both of those has a proper tooltip text.
(In reply to comment #2) > Hi ! I'm using GNOME 3.12 and all the buttons are named As I mentioned: nope. Not all the buttons are named right now. > You must be using an old version of Evince. Im testing 3.13.90. > There wasn't too much work in > making the Evince UI accessible because Evince didn't have accessible support > for any document format. Yes, probably that was the main reason.
(In reply to comment #3) > Shivani, we are in UI freeze (or will be) starting today, so if you get evince > 3.13.90 you can get a UI of evince that won't change in at least one release. As I mentioned, some of those buttons already have a proper name on the code. At least it is shown on the tooltip. And "File options" and "View options" seems suitable names from me. So the bug is that the already existing UI is not being exposed through the accessibility tools. I think that a change to expose those already existing texts will not break the UI freeze.
Created attachment 285021 [details] [review] a11y: Set accessible name for two buttons at EvToolbar This patch reuses the tooltip strings "File options" and "View options", and sets them as the accessible name of those buttons. I think that are suitable as are short-enough and meanigful-enough for them. And as I mentioned, I think that doesn't break the UI freeze, because this bug is about exposing the current UI to the AT technologies, not about changing it. NOTE: right now, gtk+ automatically exposes the gtk tooltip string as the accessible description (something that was always debatable, taking into account that most tooltips around these days are names instead of descriptions). So this patch will lead to having the same value for the accessible name and accessible description. In any case, I think that having that situation is better that the current, that is not having a name but having a description (FWIW: for accessible technologies, as a general rule, is more important having a name than having a description)
Review of attachment 285021 [details] [review]: ::: shell/ev-toolbar.c @@ +248,3 @@ gtk_widget_set_tooltip_text (button, _("File options")); + obj = gtk_widget_get_accessible (button); + atk_object_set_name (obj, _("File options")); since we are not checking the returned value nor reusing it i guess we can just do atk_object_set_name (gtk_widget_get_accessible (button), _("File options")); @@ +259,3 @@ gtk_widget_set_tooltip_text (button, _("View options")); + obj = gtk_widget_get_accessible (button); + atk_object_set_name (obj, _("View options")); Ditto.
Comment on attachment 285021 [details] [review] a11y: Set accessible name for two buttons at EvToolbar Committed with the changes suggested.
So what's now? As I mentioned on comment 5, it is really common a node having all their children with the same role, so I think that that is not something to solve. And I also mentioned that the reporter mentions that some buttons lacks an accessible name without specifying which ones. As we set the name to some of the buttons with the patch at comment 8, I think that we can close the bug, and ask to create bugs for each specific ui element lacking an accessible name. Opinions?
(In reply to comment #11) > As we set the name to some of the buttons with the patch at comment 8, I think > that we can close the bug, and ask to create bugs for each specific ui element > lacking an accessible name. Closing bug, as two specific examples of a lack of accessible names were identified and solved. If a new lack of accessible name is found, please open a new bug.