The archaeology of GNOME accessibility

Ready to give LWN a try?

With a subscription to LWN, you can stay current with what is happening in the Linux and free-software community and take advantage of subscriber-only site features. We are pleased to offer you a free trial subscription , no credit card required, so that you can see for yourself. Please, join us!

He began by defining "accessibility" as usability by people with disabilities; this usability is often provided through the use of assistive technology of some sort. When one thinks about who benefits from accessibility, it is natural to picture people like Stephen Hawking, who clearly needed a lot of assistive technology. But that is not what the most common consumers of assistive technology look like; instead, they look like his parents, who are active people in their late 60s. They are computer-literate, but they are getting older and need more affordances than they once did.

The point, he said, is that we all will benefit from accessibility at some point in our lives. He is 39 years old and has already had to make some compromises in response to aging. None of us are getting any younger, he said, so [Emmanuele Bassi] we are all the next set of consumers for accessible software. We owe it to ourselves — and to everybody else — to make accessibility work.

The GNOME project first got accessibility support during the development period between the GTK 1.3 and 2.0 releases — 18 years or so ago. This work was done by the Sun accessibility team as part of the company's effort to ship GNOME 2 on its workstations. This implementation was built around three separate components:

• The ATK toolkit, which implements a set of abstract interfaces to accessibility functionality.
• AT-SPI, which is the interface by which applications communicate with assistive technologies.
• GAIL, the implementation of the ATK interfaces for GTK.

Bassi made it clear that he was not impressed with how this design has worked out. The charitable way of explaining how it came to be, he said, was that Sun already had this sort of API for Java, so it made sense to do the GNOME work along similar lines. In reality, though, nobody knew why the Java implementation worked the way it did, but it was easier to copy it than to change it.

To complicate things further, GNOME in those days was based on the CORBA object-request broker. For the young members of the audience fortunate enough not to know about CORBA, he suggested imagining an enterprise version of any modern interprocess communication mechanism — then make it much more corporate. It had design features like a centralized authority to assign names for all users. Once upon a time, he said, all of GNOME worked that way; that is the source of the words "object model" in the GNOME name.

Much of the accessibility implementation is maintained outside of the GTK source tree, which brings problems of its own. The end result is that GNOME's accessibility support never worked all that well. But it lets managers check the "accessibility" box, which is all many of them need. Unfortunately, accessibility is not a box that can be checked and forgotten about; it is a process that must be constantly kept up with. But the GNOME project ended up mostly forgetting about it.

In the intervening years the world has changed. CORBA has been replaced by D-Bus, for example. Patience for out-of-tree modules is mostly gone. The move to Wayland is creating problems for existing assistive technology, as is the sandboxing that is increasingly being used for GNOME applications.

AT-SPI has been ported to D-Bus, he said, but the architecture of the accessibility subsystem as a whole is the same. It remains in the X11 world, where every application expects to have access to the entire system. This is a design that dates back to the days when applications were installed by the system administrator and could (hopefully) be trusted; they certainly were not acquired from random places on the Internet.

The world has changed, he said, so accessibility support in GNOME needs to change with it. The system is "stuck" and needs a redesign. But this is hard because, unlike the situation with other desktop features, it is not possible to ask users of assistive technology to contribute. To a great extent, they simply cannot perceive what is not available to them, so it's hard to even ask them to report regressions.

The first thing that needs to happen is to consolidate the various pieces, many of which have been untouched for years. Some new functionality has been added, mostly to match new features provided by browsers, but as a whole GNOME accessibility support just doesn't really work. The abstraction layer doesn't really abstract anything, so changes typically have to be made in many places. The toolkit needs to be simplified; as things stand now, application developers expect GTK to take care of everything, but that is not the case. There is also a need for funding; this work is not trivial and it's not reasonable to expect it to be done by volunteers.

This year, he said, the GNOME Foundation (where he is employed) has directed him to work on this problem for the upcoming GTK 4 release; he has been doing that for the last six months. There has been a lot of "archaeology" involved to understand it all. He has been working to pull a lot of abstracted stuff back into GTK; developers will not have to go to the ATK reference manual anymore, he said, because it won't exist. He has also been working on portability; accessibility support in GTK doesn't currently work on obscure systems like Windows.

There is still a need for some abstraction, he said, but it should be based on concepts rather than code. GNOME is increasingly using cascading style sheets for its drawing API, so it is natural to look at what the web is doing in the accessibility area. There is a W3C standard called WAI-ARIA that defines many of the abstract concepts needed for accessibility:

• An element is an accessible part of the user interface.
• Each element has a role describing what it does: a checkbox, a slider, etc.
• Attributes describe things the element has: properties, visibility, labels, state, relationships with other elements, etc.

Bassi is working on an accessibility implementation around these concepts. He described it briefly, but this is the point where he was told that he was running out of time. The resulting increase in the pace of the presentation made the information less ... accessible ...

Application developers, he said, will need to follow the WAI-ARIA rules to ensure the accessibility of their systems. That means using the provided accessible elements rather than rolling their own, for example. The semantics of widgets should not be changed. Any widgets that are accessible with a mouse pointer should also be accessible from the keyboard. Widgets need an accessible label. And so on.

He is doing some work with gtk-builder-tool to ensure that accessibility information is added to interfaces where it needs to be. There is also a new assert mechanism that can verify that accessibility information is changed when elements of the interface are changed, hopefully preventing accessibility regressions.

The current state is that the new accessibility API is nearly finalized; only a few small details remain. The GTK widgets are being ported to this new API. He is writing a new test suite for this API, and documentation is in progress. He is also working on implementing the AT-SPI backend to talk to assistive systems — necessary since, without it, the rest of this work won't actually do anything.

Bassi concluded with some suggestions for anybody who would like to help with this effort. He would like to see people writing more tests, and documentation as well. Ports to Windows and macOS need to be done. Accessibility for sandboxed applications needs to be improved; they need access to information and assistive technology but should not have access to the entire desktop. And, naturally, there is always a need for funding to push this effort forward.