The first release candidates for LibreOffice 4.3.0 are already bouncing around the internet and, besides great new features like the ones I’ve been explaining in my latest posts, they come with a set of fixes to ease the life of screen reader users and developers alike. This is, once again, a part of the accessibility work we do at Igalia.

Back in April, when the Gran Canaria hackfest took place, I started working on the bug #71556. The problem was that typing on a document triggered a lot of unnecessary text-attributes-changed events. These events had a variety of origins, but most of them were caused by modifications in the internal text attribute rsid, used for change tracking and with no relevance per se for the user. The bug is not completely fixed, but addressing the problem with rsid attribute allowed us to get rid of the most annoying part of it; now LibreOffice only sends one unnecessary event when we type the first character in a new paragraph and not with every keystroke.

Bug #71558 is also related with the same kind of events; in this case, text-attributes-changed was not being triggered when a word became marked as misspelled. Actually, the spell-checking status is not internally treated as a text attribute and because of that there were no events indicating its change. The patch explicitly raises the event which lets the accessibility code check the status of the text attributes and find out the spelling mistake. While I was working on this issue, I also detected a weird behavior when checking the text attributes through the Python API; it resulted to be a bug in the bridge between AT-SPI and ATK, which I reported and fixed too.

A triaging session took me to bug #74681; the main issue reported there had already been fixed for a while and only small bits regarding missing accessible names in some buttons were missing. I fixed that allowing toolbar buttons to use their tooltip text as the accessible name if it is not explicitly set, and now the paragraph properties panel is fully accessible.

Finally, I retook the work I had been doing in relation with ATK roles at bug #39944 and detected wrong mappings for LibreOffice EDIT_BAR, EMBEDDED_OBJECT and HYPER_LINK accessible roles. I fixed them and opened a ticket in ATK bugzilla to create ATK roles for the five cases that were still registering custom roles. Once that ticket is managed, hopefully we will be able to close bug #75191 too, which is related with the deprecation of atk_role_register.

These fixes are added on top of the ones coded in February hackfest, making 4.3.0 the most accessible LibreOffice so far… Until the next version arrives, of course!

Accessibility is one of the areas of interest for us at Igalia, that’s why I traveled to Brussels some weeks ago to take part in the LibreOffice UX hackfest organized by The Document Foundation and kindly hosted by Betacowork. My colleage Joanmarie Diggs, maintainer of Orca, had identified a set of bugs that will be instrumental in improving the experience with the screen reader; as she keeps saying, “Orca can only provide access to what is made accessible.”

Before diving into the specifics, let me introduce the accessibility layers of LibreOffice first. Due to its multi-platform nature, LibreOffice provides its own Visual Components Library (VCL), with a graphical toolkit in the fashion of GTK+, Qt, etc. It serves as an operating system abstraction, and it is mapped to system-specific libraries whenever possible. When it comes to accessibility, there is a set of internal accessibility APIs that can be translated into ATK objects and functions in the same way it can be translated to IAccessible2 API in Windows.

The first thing I tackled was implementing and improving the accessible roles exposed by LibreOffice. Better role support means smarter client applications: for example, an object registering itself as a spreadsheet document allows the screen reader to make some assumptions about the structure of that document and present its contents more efficiently, and in a more tailored fashion, than it could for a generic document. And navigation by heading only works if headings claim to be headings rather than paragraphs.

Bug #39944 is about adding support for new(ish) ATK roles which LibreOffice wasn’t using yet. Checking the list of existing internal roles we find out that some of the new roles fit properly in the existing API, for example group box and comment internal roles match with ATK’s grouping and comment. But other roles had to be added from scratch. This was the case for the new, specific roles for spreadsheet, text and presentation documents that I added to LibreOffice API and linked to their ATK relatives.

Bug #35105 was a trickier one, because it looked more simple than it was… The problem as reported was that headings in text were not exposed using the proper heading role. But as I dug deeper, I discovered a much more complicated issue: paragraphs that could become headings, and the opposite, as a result of editing the document. LibreOffice lacked support for accessibility objects changing their roles, so I added a new event to the API to notify role changes, and connected that event with atk_object_set_role.

I also spent quite some time working on bug #35107. Again, it looked like a simple role-support bug, but I had learned not to trust the first impression. To debug this one, I first had to learn about the ATK hypertext interface and hyperlink objects. Having done so, I was able to verify that LibreOffice’s existing hypertext implementation was working properly. The same didn’t hold true for the hyperlink; in particular, the implementation of hyper_link_get_object in LibreOffice was wrong. A patch is still pending because it requires involving the third member of the ATK hyper-family, AtkHyperlinkImpl, of which there is no trace in LibreOffice (yet) and thus has to be implemented from scratch. Anyway, it was an interesting debugging and documentation-reading exercise.

Happy hacking!

Flavors from Brussels