Mena Quintero: Paying technical debt in our accessibility infrastructure [LWN.net]

On his blog, Federico Mena Quintero posted a transcript of his recent talk at GUADEC 2022 on the technical debt in the GNOME accessibility infrastructure—and what he has been doing to help pay that down. He began the talk by describing the infrastructure and how it came about:

Gnome-shell implements its own toolkit, St, which stands for "shell toolkit". It is made accessible by implementing the GObject interfaces in atk. To make a toolkit accessible means adding a way to extract information from it in a standard way; you don't want screen readers to have separate implementations for GTK, Qt, St, Firefox, etc. For every window, regardless of toolkit, you want to have a "list children" method. For every widget you want "get accessible name", so for a button it may tell you "OK button", and for an image it may tell you "thumbnail of file.jpg". For widgets that you can interact with, you want "list actions" and "run action X", so a button may present an "activate" action, and a check button may present a "toggle" action.
However, ATK is just abstract interfaces for the benefit of toolkits. We need a way to ship the information extracted from toolkits to assistive tech like screen readers. The atspi protocol is a set of DBus interfaces that an application must implement; atk-adaptor is an implementation of those DBus interfaces that works by calling atk's slightly different interfaces, which in turn are implemented by toolkits. Atk-adaptor also caches some things that it already asked to the toolkit, so it doesn't have to ask again unless the toolkit notifies about a change.
Does this seem like too much translation going on? It is! We will see the reasons behind that when we talk about how accessibility was implemented many years ago in GNOME.

to post comments

Mena Quintero: Paying technical debt in our accessibility infrastructure

Posted Aug 8, 2022 11:01 UTC (Mon) by illume (subscriber, #152680) [Link]

Amazing work. This type of quality engineering really deserves props.

There's not many people who know how to do it, and very few people who truly know the benefits.

- This helps scale the effort to more people because it makes it easier for every other developer that comes later.
- After doing this type of stuff, most projects get a lot more contributors.
- Quality developers are attracted to quality code bases.
- The other great insight from this article is how it's a great way to learn a code base.

Well done, and thanks for sharing the write up of your work :)

ps. Low code coverage and high lint/warnings in areas of code are strong signals for areas of low quality code and bugs. It's good to make a note to review those areas, even before code coverage is improved, or lint warnings removed. It can often be that these areas aren't used by people at all (because of the low quality). Such areas can sometimes be completely removed!