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