After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 734912 - Nodes to be named correctly for a11y
Nodes to be named correctly for a11y
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-08-16 17:02 UTC by Shivani Poddar
Modified: 2014-09-29 17:13 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
a11y: Set accessible name for two buttons at EvToolbar (1.85 KB, patch)
2014-09-01 14:11 UTC, Alejandro Piñeiro Iglesias (IRC: infapi00)
committed Details | Review

Description Shivani Poddar 2014-08-16 17:02:26 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.
Comment 1 Shivani Poddar 2014-08-16 20:07:15 UTC
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.
Comment 2 Juanjo Marín 2014-08-17 10:50:59 UTC
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.
Comment 3 José Aliste 2014-08-18 13:21:15 UTC
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?
Comment 4 Shivani Poddar 2014-08-29 16:18:19 UTC
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 :)
Comment 5 Alejandro Piñeiro Iglesias (IRC: infapi00) 2014-09-01 12:17:48 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.

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.
Comment 6 Alejandro Piñeiro Iglesias (IRC: infapi00) 2014-09-01 12:18:06 UTC
(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.
Comment 7 Alejandro Piñeiro Iglesias (IRC: infapi00) 2014-09-01 12:19:59 UTC
(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.
Comment 8 Alejandro Piñeiro Iglesias (IRC: infapi00) 2014-09-01 14:11:51 UTC
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)
Comment 9 Carlos Garcia Campos 2014-09-01 16:26:58 UTC
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 10 Alejandro Piñeiro Iglesias (IRC: infapi00) 2014-09-02 11:19:27 UTC
Comment on attachment 285021 [details] [review]
a11y: Set accessible name for two buttons at EvToolbar

Committed with the changes suggested.
Comment 11 Alejandro Piñeiro Iglesias (IRC: infapi00) 2014-09-02 11:23:44 UTC
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?
Comment 12 Alejandro Piñeiro Iglesias (IRC: infapi00) 2014-09-29 17:13:22 UTC
(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.