A recap of Chromium dialog accessibility enhancements

It’s been a bit more than a year since I started working on Chromium accessibility. Although I’ve worked on several kinds of issues, a lot of them had to do with UI dialogs of some kind. Browser interfaces present many kinds of dialogs and these problems affected all the desktop platforms. This post is a recap of all the kinds of things that have been fixed related with different uses of dialogs in Chromium!

Continue reading

Event management in X11 Chromium

This is a follow-up of my previous post, where I was trying to fix the bug #1042864 in Chromium: key strokes happening on native dialogs, like open and save dialogs, were not reported to the screen reader.

After learning how accessibility tools (ATs) register listeners for key events, I found out the problem was not actually there; I had to investigate how events arrive from the X11 server to the browser, and how they are forwarded to the ATs.

Not this kind of event

Continue reading

The trip of a key press event in Chromium accessibility

It’s amazing to think about how much computing goes into something as simple as a keystroke that we just take for granted. Recently, I was fixing a bug related to accessibility key events, and to do this, first I had to understand the complex trip that these events take when they arrive to the browser – from the X server until they reach the accessibility system.

Let me start from the beginning. I’m working on the accessibility of the Chromium browser on Linux. The bug was #1042864: key strokes happening on native dialogs, like open and save dialogs, were not reported to the screen reader. The issue also affects Electron-based software, one important example is Visual Studio Code.

Continue reading

Dialog accessibility in Chromium

In the latest weeks I’ve been identifying and fixing several issues related to accessibility on dialogs (called “bubbles” in the code base), specially but not limited to the Linux platform.

It all started with the “Restore pages” dialog that appears when restarting after a browser crash. ATs, like screen readers, were not being notified about the presence of that dialog due to it using an incorrect role, which made it impossible for a blind user to find it out unless by chance, tabbing through the application.

While I was working on that, I detected more issues related to this and other dialogs, so I started reporting and fixing individually. They also led me to an existing meta-bug related to the “restore pages” dialog and accessibility… In the end, this is what I accomplished:

Continue reading

LibreOffice hackfest in Madrid

Earlier this month, I attended a LibreOffice hackfest that has been held in Madrid. My goal for this hackfest was to work on the accessibility of the suite, in particular with the problem exposed in bugs 35652 and 91739, which together prevent the “say all” feature in ATs from working properly with LibreOffice.

The root of the problem is that LibreOffice only exposes a subset of the document through the accessibility APIs; in particular, only the visible parts of the document. This makes sense from the performance point of view, specially for huge documents, but poses a challenge for ATs.

To workaround this behavior, LibreOffice provides some means to navigate to off-screen elements through the flows-to relation. The last paragraph in the visible area has a relation of this kind with the next paragraph even if the latter is not on screen. Unfortunately, the associated accesibility tree does not reflect a proper parent-child structure when these relations are used: objects which should be present are absent, because they actually are never added to the tree. Additionally, when the user changes the visible area of the document, the accessible tree is rebuilt to contain only the visible contents of the document and it leaves orphaned objects left and right.

The proposal from my colleage Joanie, maintainer of Orca, is creating a new set of top-level children for the accessible document object to represent the pages in the document. These would be exposed through the accessibility APIs at any time, regardless of the visibility of said pages, and the actual contents would be lazily loaded when required by ATs. This should expose information to ATs properly in a tree structure and keep most of the document unloaded until really needed. Besides, the problems that appear when navigating flows-to relations or changing the visible area should be addressed to keep the accessible tree clean and up-to-date.

Sadly, I could make no significant advances in the implementation of the above solution. First, the notion of accessible pages doesn’t even exist in Writer, it should be implemented completely from scratch. Besides, the “only visible objects exist” logic is deeply rooted in the code and it would need much more work than three days of hackfest. Still, the analysis work has been very valuable to see where the problems are and pave the way to fix them.

Finally, I’ve also been helping a new contributor to land his first patches in LibreOffice. We started with a cleanup of ATK roles, one of the first tasks I touched when working on accessibility in LibreOffice which was still ongoing, and now it’s close to be finished. We also tried to debug a docx import problem regarding the flip property and instead found a regression in image flip for certain types of bitmaps. The work resulted in another patch for the latter problem which is already merged.

This has been a great occassion to hang out with the community, help newcomers and get some hacking done. I’m very thankful to Igalia for having sponsored my trip and stay in Madrid. See you in the next event!

Igalia & LibreOffice