AccessKit: ein neues Open-Source-Projekt, das helfen soll, mehr Apps zugänglich zu machen
There’s just about nothing more frustrating for blind people than trying to use an app, only to find that the app is inaccessible. Maybe your screen reader can’t read a key part of the app, or maybe it can’t read anything at all. When apps are developed using standard buttons, edit boxes, list boxes, tables, or other user interface elements, it’s not hard to make them accessible. But some apps are developed using a non-standard user interface toolkit, and these toolkits are completely inaccessible. Implementing accessibility from scratch in a user interface toolkit is difficult and time-consuming, so it usually doesn’t get done, except in the top few user interface toolkits with heavy corporate backing. Sometimes it’s truly necessary for an app developer to use a custom user interface toolkit, and sometimes it’s not, but regardless, we end up with inaccessible apps.
This problem is especially urgent for apps that are critical to particular jobs. It’s not uncommon for a blind person to be unable to get a particular job because the job requires the use of an app that’s inaccessible. These are often niche apps for which the usual economic incentive to implement accessibility, namely selling to the government and educational sectors, doesn’t apply. So we urgently need a solution that breaks down as many of the barriers as possible to making the long tail of apps accessible.
As with the work Pneuma Solutions is doing on remediation of documents and meeting content, machine learning can help with this problem. Apple is leading the way in this area with the Screen Recognition feature built into iOS, and the results so far are promising. However, this technology isn’t yet available on all computers and devices, and the results are often not satisfactory. We can’t wait for this solution to mature and be more widely adopted; we need another approach that will be practical in the shorter term. Also, many developers of both apps and user interface toolkits are willing to make their software accessible, if only it weren’t so difficult and time-consuming. These developers are already willing to meet us halfway; now we need to do the same.
That’s where my new open-source project, AccessKit, comes in. The goal of AccessKit is to provide shared infrastructure for making apps accessible, across as many platforms and programming languages as possible. With AccessKit, a developer working with multiple platforms won’t have to implement accessibility for each platform from scratch. Another goal of AccessKit is to be better documented and easier to use correctly than the existing platform-specific accessibility APIs such as UI Automation for Windows or Cocoa accessibility for Apple platforms. After all, a broken accessibility implementation can be almost as frustrating as no accessibility at all.
AccessKit is still early in its design and development, but it’s already attracting interest from other developers, including code contributions from one other developer. And now I have the great privilege of receiving funding from Google to work part-time on this project, starting with the Windows implementation. I look forward to usable results by the end of this year.
I’m sure any developers reading this will want to know more about how AccessKit will work. The short version is that AccessKit will provide a cross-platform accessibility abstraction that’s heavily inspired by the Chromium browser engine. This abstraction is based on serializable data structures, thus minimizing the overhead of interfacing between programming languages. AccessKit will be implemented primarily in the Rust programming language, which provides a unique combination of reliability and efficiency. However, AccessKit will be usable from a variety of programming languages. More details are available at the AccessKit GitHub repository.
As an open-source project, AccessKit needs participation from the developer community to be successful and sustainable. In particular, I’d appreciate contributions from developers that are proficient in the Rust programming language. The overall design of AccessKit is still fluid, so it’s too early for me to delegate much implementation work. What I do need at this point is peer review, especially from developers that are more experienced with the Rust language than I am. If you’re interested, please join us on GitHub.
In closing, a big reason why I left Microsoft to cofound Pneuma Solutions is that I want to have the freedom to work on accessibility-related projects that I believe will have a great positive impact for our community, beyond a single platform. I’m still enthusiastic about the work we’re doing at Pneuma Solutions, and that work will continue. With AccessKit, I now have the opportunity to solve a problem that has weighed heavily on my mind for many years. I look forward to working with the software development community to make many more apps accessible.