Magnifier focus and caret tracking: Finally, the focus and caret tracking feature of GNOME Shell’s magnifier has landed. Now the magnified view automatically follows the writing caret and changes in focus so you can always see where you are without having to move the mouse. You can read more about this work in this post written by Magdalen Berns, the GSoC student that implemented this feature.

GNOME Shell improvements: One of the new features of GNOME 3.10 is the new System Status Menu. This menu includes several new visual elements which were reviewed and enhanced in order to ensure they would be fully keyboard navigable and accessible through accessibility tools like Orca. Keyboard navigability was also added to the calendar pop-down in the shell panel, though admittedly there is some room for improvement which we hope to address in GNOME 3.12.

PDF accessibility: Evince keyboard support has landed. Now users can press F7 to activate a caret for navigation and selection within the document being read. This new support was also made to work with Orca, so that PDF content can be accessed by users who are blind directly in Evince. Support for tagged PDFs is currently being added to Poppler and will be used to further improve accessibility support in Evince. This work is being done by Igalia, having been funded by the Friends of GNOME accessibility campaign. You can read more about this work on Antía Puentes’s “Accessibility in Evince” and Adrián Pérez’s “Tagged-PDF: Coming to a Poppler near you” blog posts.

A new global keyboard shortcut for Orca: Now the screen reader can be easily turned on/off at any time by just pressing Super+Alt+S. This might seem like a small change, but it is in fact a really big step that allows more distros to be more accessible out of the box.

ATK deprecations (a lot): While this does not directly affect the user experience, over time it will make developers’ lives easier, and will also lead to cleaner and more easily maintainable code. The first one is the simplification of what used to be extremely confusing and hard-to-implement methods to get a substring from a text related object. We had been talking about this problem for a long time, and finally agreed upon the new API at this year’s GUADEC. Mario Sánchez then added the new method to ATK and AT-SPI2 and also implemented it in WebKitGTK. The other major change is related to focus handling. One signal and six methods were deprecated, simplifying the situation *a lot* in that regard.

What’s next?

Captain Obvious to the rescue: 3.12. Although 3.10 was better than 3.8, our plan is making 3.12 even better. Like a lot of other teams, we started the new cycle listing, analyzing and prioritizing everything we need to do, using the Montreal Summit as a kickoff for 3.12 and making the most of being able to talk face-to-face with other GNOME developers. There are always changes to keep up with: new applications, new widgets, and new deprecations. But right now, the more important change in progress is Wayland. A lot of work was done for 3.10, so that we have the possibility to run GNOME 3 using a Wayland session. It is still not production ready (in my humble opinion, it is alpha status), but the plan is filling the gaps for 3.12, and that includes accessibility.

But Wayland is not the only topic for 3.12. During the weekly Accessibility Team meeting after the summit, we discussed all the improvements planned for 3.12:

Complete Wayland support

Create a new asynchronous API for AT-SPI2

Add configuration UI for some already-implemented magnifier features (focus/caret tracking and tinting)

Having worked on that stuff in poppler before, I’m curious if there’s any notion of changing the text api down there to better support cursors? TextOutputDev has an API that was designed around rectangular selection, but has been abused a bit to select text between points. However it always seemed to me it would make more sense to attempt to derive a structure more like tagged pdf/atk expect, with the text already chunked in reading order so that selection was a character range? IIRC the code was a bit overcomplicated in this area, having to guess over and over again what the next character is as it iterates over blocks; really it needed a new OutputDev with a different API, but I lacked the C chops and spare time to push for bigger change like this.

There’s been at least one regression from a keyboard accessibility which is the cog that allows selection of desktop on the gdm login screen. Not sure if that is a regression elsewhere the shiny new cog is used