accessibility: main application arias inaccessible to assistive technology users

[albertotirla]

Describe the bug A clear and concise description of what the bug is.

when using a screen reader such as orca, important parts of the application are inaccessible. Furthermore, upon opening a book, the focus gets stuck in an adw entry, as such tab presses used to get to the next control get rendered as a tab character, which is a behavior all adw entries configured a certain way share. Unfortunately, I can not provide you with the control id of that entry, because the screenreader doesn't read the entry placeholder, if any, and whether that is an entry in the first place is debatable I suppose, with so little info to go on. A bit of additional info though, the screenreader does say <void symbol> when navigating with the virtual cursor to try to locate that entry box. That's the tricky part with these accessibility bugs, when stuff partially works, that's one thing, I can offer more targetted advice, but in most cases, it either works, mostly works, or doesn't work at all and the only thing I can do is report what's not visible.

To Reproduce Steps to reproduce the behavior:

1. Install the orca screenreader and its dependencies. Because a screenreader is a system component, it can't be packaged in a flatpak yet
2. Turn the screen reader on. This can either be done with the help of your desktop environment of choice, or by simply invoking orca & from a terminal
3. Open foliate, flatpak is recommended because that's what I tested with
4. Get to the view for a book, either by adding a new one altogether, or opening an existing one

Expected behavior A clear and concise description of what you expected to happen.

the book view should perhaps show a table of contents, where supported, then the next press of the tab key should land me on a document widget, with perhaps the caret navigation property enabled, which effectively shows what sighted users should see, complete with whatever HTML semantic formatting is made available to them, either because the book is in the epub format, or it embeds extra semantic informations, see accessible PDF documents.

Screenshots If applicable, add screenshots to help explain your problem.

not applicable, this is an accessibility issue, a semantics one so to speak, the visible interface is not affected or criticised here

Version:

• Foliate version: 3.0.1
• OS/Distribution and version: name = "Arch Linux", kernel = "6.6.1-arch1-1"
• Desktop environment: MATE 1.26.0
• Installation method: Flatpak

Additional context Add any other context about the problem here.

the accessibility of the program can also be tested by trying to perform keyboard navigation as a sighted user, no assistive technologies required, as well as with the help of a tool made by gnome, called accessiser if I didn't totally misspell it. In case the interface of the program seemns far too user-hostile to you, you could try to use the gtk inspector, which which you probably are familiar already. Somewhere in its interface, if you're using a new enough version, there's an accessibility checker tool, I'm told it's a tab. I hope this additional so called context could help fix this particular bug, because it makes the app almost unusable, or at least unusable for its intended purpose, for people requiring assistive technologies.

[johnfactotum]

As far as I can tell, the WebView does have focus when you initially open a book, and pressing Tab subsequently will move through the focusable HTML elements, if any, as expected (though the focus seems to be totally lost after it reaches the end, which I'm not sure how to fix).

It looks like this might be a WebKitGTK issue because the screen reader does not work for me in Epiphany, either. It does not read anything from the WebView, even if you enable caret browsing. And it has the same issue where the focus is irrevocably lost when tabbing beyond the list of focusable elements. (To reproduce this, open Epiphany, type example.com, press Enter, and press Tab. Now the focus is on the link "More information…". After pressing Tab again at this point, the focus does not seem to be on any widget at all, and pressing Shift+Tab does not move the focus back to the "More information…" link.)

[albertotirla]

that's interesting and very weird, because the qt webview is similarly hostile to screenreaders, I wonder if it's something inherent to the webviews themselves? So then, is that what the webview gets reported as, a libadwaita entry? because that's what the screenreader reads when I open the book, and pressing tab apparently inserts the tab character, but I can't delete any of the tabs afterwards.

[johnfactotum]

For me, when the book is opened, it only reads the title of the window (which is the title of the book), and that's it. It doesn't announce the WebView at all. Clicking on other widgets and clicking on the WebView again, it still says nothing.

In Epiphany, it says "filler" when the WebView is focused.

[albertotirla]

currently, it's worse, now it no longer reads the webview at all, which wasn't the case before. Is caret navigation not enabled in gtk4? Atral document viewer, the one mate uses, is initially inaccessible like that, but pressing f7 activates a dialog where I can turn on caret browsing, which makes it instantly accessible. Is that a gtk3 only thing?

[johnfactotum]

The GNOME 46 changelog says that in GTK 4.14 "libraries such as WebKit with their own accessibility trees can now bridge them with the accessibility tree provided by GTK." Not sure if this means that WebView contents should be accessible now.

Caret browsing can be enabled on the WebView, however the paginator of foliate-js does not work well in caret browsing mode, which is why I haven't added it. See #761. Though probably it should be added even without proper support from the paginator because it would at least be usable in scrolled mode.

[albertotirla]

yes, that's exactly what that means. Caret browsing is required especially for selecting and copying passages from a book, but there are other uses too. However, if you update to the gnome 46 runtime, there are greatter chances of this working out of the box, at least somewhat.