Our last post on accessibility in GTK4 was a while ago, time for an update.
Thankfully, we have Lukáš Tyrychtr at Red Hat working on accessibility now.
Accessibility – How does it work?
One of the bigger changes in accessibility from GTK3 to GTK4 was that we have a new application API that is modeled on the ARIA specs from the web.
The high-level picture to keep in mind is
app → ARIA → AT-SPI → accessibility bus → AT
AT stands for accessibility technology here. In practice, that mainly means orca, the well-known screen reader (although there is a new contender, with the odilia project).
The new layer provides APIs such as
void gtk_accessible_update_state (GtkAccessible *self,
GtkAccessibleState first_state,
...)
that let apps set accessible attributes of their widgets.
ARIA layer improvements
Since we’ve introduced it in GTK4, the application API layer has only seen moderate changes. That has started to change over the last 9 months or so, since Lukáš is working on it.
One thing that he has started to do is adding public interfaces so that third-party widgets (such as libadwaita) can provide full accessibility support. The first such interface is GtkAccessibleRange (new in 4.10), for range widgets like GtkScale. We are looking at adding more, notably a text interface. It will be needed to make terminals accessible.
In the 4.12 cycle, we have done some work to make our implementation match the ARIA specs more closely. This involved changing the roles of some widgets: our default role is now ‘generic’, and toplevel windows use the ‘application’ role. We’ve also redone the way accessible names and descriptions (i.e. the things you hear orca read) are computed, to match the spec.
Another improvement is that most of our widgets now have the necessary labels and relations to make orca read them. If you find that there are still things missing, please let us know!
AT-SPI translation improvements
It is no secret that we would like to see some modernization of the AT-SPI D-Bus APIs. But for now, it is what we have to work with. Our translation layer works by lazily putting just the objects on the bus that ATs have asked for, to avoid creating too much bus traffic.
One of the recent improvements in our translation is that we are now using GtkAccessibleRange, so third-party range widgets can be accessible.
We have also fixed problems with the selection implementations for GtkNotebook and GtkStackSwitcher, so ATs can now change the selected tab in notebooks and stacks.
Tools
All of this is nice to hear, but if you are an app developer, you may want to know how you can find and fix accessibility problems in your app.
It is very instructive to just turn on the Screen Reader and see what it says as you navigate through your app. But we also have some tools to help you evaluate the accessibility support of your app.
The GTK inspector has a page that shows accessibility information:
It recently was improved to show not just the properties, states and relations that are set on each widgets, but also the name and description that GTK computes and passes to ATs
- that is the text that orca reads.
Another tool in the inspector is brand new: the accessibility overlay shows warnings and recommendations that are based on the ARIA authoring guidelines.
It looks like this:
It is not perfect, but it should give some quick insights on where you can improve accessibility.
Summary
GTK 4.12 will have better out-of-the-box accessibility and new tools to help you make your app accessible.
Enjoy! ❤️