GNOME Bugzilla – Bug 677348
[Meta] Make PDF in Evince accessible with orca
Last modified: 2018-05-22 14:37:35 UTC
Created attachment 215497 [details] This is the PDF i wanna access. Hi All, I would read an PDF file via Orca. But it wont seems to work. I can access the hole application exept the pdf content. It would be good if orca can read the pdf content. I attached the PDF file.
Evince supposedly got accessibility implemented, but I have yet to see this. Orca cannot provide access to a document it cannot even see. :( In addition to the lack of accessibility in any and all shipping versions of Evince which I have seen, there are also other bugs which need to be fixed such as these evince bugs: * https://bugzilla.gnome.org/show_bug.cgi?id=638905 * https://bugzilla.gnome.org/show_bug.cgi?id=639403 * https://bugzilla.gnome.org/show_bug.cgi?id=639932 Transferring this bug to the correct product.
I think evince was accessible for a sort time, but never in a distribution or release. Gtk a11y changes just when we add accessibility to evince so it didn't work anymore. I've just started to work again in evince a11y so I've fixed the current a11y support. I'll attach a patch that fixes a11y in evince today.
Created attachment 220318 [details] [review] fixing ev-view-accessible creation I also added a repository in github if someone prefer to review, test, fork, etc.
(In reply to comment #3) > Created an attachment (id=220318) [details] [review] > fixing ev-view-accessible creation > > I also added a repository in github if someone prefer to review, test, fork, > etc. I forget the github branch: https://github.com/danigm/evince
Review of attachment 220318 [details] [review]: ::: libview/ev-view-accessible.c @@ +34,3 @@ #define EV_IS_VIEW_ACCESSIBLE(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj), EV_TYPE_VIEW_ACCESSIBLE)) +static gpointer accessible_parent_class; G_DEFINE_TYPE_WITH_CODE already defines a parent class pointer. In your case a variable called ev_view_accessible_parent_class @@ +68,3 @@ +struct _EvViewAccessible +{ + GtkAccessible parent; EvView is a container. So the accessible parent object should be a GtkContainerAccessible @@ +74,3 @@ +struct _EvViewAccessibleClass +{ + GtkAccessibleClass parent_class; Ditto. EvViewAccessibleClass parent class should be a GtkContainerAccessibleClass. Doing this you are losing all the functionality defined on those classes. All the factory coded removed was intended to get those types indirectly. @@ +112,3 @@ + AtkObjectClass *atk_class = ATK_OBJECT_CLASS (klass); + + accessible_parent_class = g_type_class_peek_parent (klass); G_DEFINE_TYPE_WITH_CODE is already calling peek_parent (with ev_view_accessble_parent_class) ::: libview/ev-view.c @@ +4679,3 @@ ev_view_get_accessible (GtkWidget *widget) { + return atk_gobject_accessible_for_object (G_OBJECT (widget)); Is this working? Gtk is not using AtkGobjectAccessible. GtkAccessible is a AtkObject subclass, and with this patch, EvViewAccessible is a GtkAccessible subclass.
(In reply to comment #5) > @@ +74,3 @@ > +struct _EvViewAccessibleClass > +{ > + GtkAccessibleClass parent_class; > > Ditto. EvViewAccessibleClass parent class should be a > GtkContainerAccessibleClass. Doing this you are losing all the functionality > defined on those classes. All the factory coded removed was intended to get > those types indirectly. In general this patch is doing something that I like, that is removing all that factory coded related code (that IMHO, it is a big hack), but as I'm saying there, it is not using the proper accessible parent class. I have started a thread about that on gtk-devel: https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00001.html Lets see if I get some answers.
(In reply to comment #6) > I have started a thread about that on gtk-devel: > https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00001.html > > Lets see if I get some answers. Seems you did. Thanks! Does this look like something we can get into place in time for 3.8?
(In reply to comment #7) > (In reply to comment #6) > > > I have started a thread about that on gtk-devel: > > https://mail.gnome.org/archives/gtk-devel-list/2012-August/msg00001.html > > > > Lets see if I get some answers. > > Seems you did. Thanks! Does this look like something we can get into place in > time for 3.8? During the boston summit we resumed this discussion. GTK maintainers agreed to publish some of the gtk accessibility headers. Enough to get third-party applications and toolkits to extend that work. Current plan is having that ready at least for 3.8. You can find a more detailed explanation here: http://blogs.gnome.org/mclasen/2012/10/08/gnome-summit-sunday/ In the same way, taking into account that there are more that one bug preventing evince to be accessible (see comment 1), and the description of the bug is really general, I think that in order to coordinate this effort, it would be good to use this bug as a meta-bug of the bugs preventing Evince to be accessible with Orca. I will create a new bug for the "headers" stuff, that was initially tried to be solved on comment 3.
I'm also adding poppler bugs that affects evince support with orca on the "See Also" region.
Is there an chance to get simple a11y support for reading pdf with gnome 3.8? It would be a real great feature :).
(In reply to comment #10) > Is there an chance to get simple a11y support for reading pdf with gnome 3.8? > It would be a real great feature :). Finally being able to read documents that everyone else can already read just by looking at the screen is not a "feature"; it's a bug fix. And one that is long overdue.
Created attachment 232824 [details] [review] Do not use AtkFactory to create the EvViewAccessible Could someone confirm this patch is correct?
(In reply to comment #12) > Created an attachment (id=232824) [details] [review] > Do not use AtkFactory to create the EvViewAccessible > > Could someone confirm this patch is correct? Hi, I reviewed this patch, and tested a little. The patch seems ok to me. In the same way, after trying it and tested with accerciser, I get the test of the current pdf page exposed as a whole. Anyway, take into account that this patch doesn't solve all the aspects of this bug. This has become a kind of metabug, depending on several bugs. This patch only solves bug 685828, so my advice is push it and only close bug 685828
(In reply to comment #13) > (In reply to comment #12) > > Created an attachment (id=232824) [details] [review] [details] [review] > > Do not use AtkFactory to create the EvViewAccessible > > > > Could someone confirm this patch is correct? > > Hi, I reviewed this patch, and tested a little. The patch seems ok to me. In > the same way, after trying it and tested with accerciser, I get the test of the > current pdf page exposed as a whole. > > Anyway, take into account that this patch doesn't solve all the aspects of this > bug. This has become a kind of metabug, depending on several bugs. This patch > only solves bug 685828, so my advice is push it and only close bug 685828 Thanks for reviewing, I had forgotten the other bug, sorry.
maybe its not important(so just ignore it), but i recognize that some bugs in the "depends on" list of this bug are "duplicated" via an other metabug. for example the bugs 701727, 701728,701729 are indirect present via the bug 701726 (only those three are in the metabug). So i think its an little redundant. The bug 701737 is indirect via 701785 and 701786 present 701749 is indirect applied via 701814. so i think the bugs 701737,701749,701727,701728,701729 in the "depends on" list ´are redundant. maybe this makes the overall view of the "depends on" list better.
-- 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/evince/issues/283.