Speak Up
I’m working on a new thing
I left my job in December. For a lot of reasons. The main one being that I spend most of my time these days doing political organizing in Detroit, where I was born and had been away from for too long. But… it’s hard to do a lot of that work in Michigan, in the winter, so i fired up Xcode and started exorcising some ideas.
Two months later I’ve got something worth talking about.
Building a screen reader for macOS is an arcane science
Before VoiceOver shipped, the public accessibility APIs in AppKit and in HIServices were conceived as agnostic interfaces for anyone who wanted to build a screen reader. some of the quirks of these APIs are there because there was no real client to poke them and make sure they made sense.
There is still, theoretically, support for third party assistive technology (AT), the umbrella a screen reader would fall under, but it’s not a trivial task and it’s simply not possible without dipping in to SPI1.
But it doesn’t have to be
The current state of accessibility on all of the Apple platforms is, like almost everything in the Apple universe, organized in a top down fashion. An app becomes accessible because Apple does the work to make it accessible, because the app developer does the work to make it accessible. There’s very little that can be done, even by well motivated community members, to make an app neglected by Apple or by a third party developer better.
I believe it is possible to produce infrastructure that democratizes assistive technology for macOS. I want the barrier to entry to be as low as active interest and time. The future of fundamental technologies serving disabled people ought to be in disabled peoples hands.2
This coming week I’ll be prepping open source components I’ve built for release. Hopefully you’ll find them well organized and easy to jump into. Once I’ve got all the pieces out in the world I’ll be seeking community involvement to steer the future of the project and to figure out what problems are most useful to solve.
In addition, I’m working on the first app to sit on top of this infrastructure. A brand new screen reader for macOS, which i’ve given the project code name SpeakUp.
Accessibility as autonomy
SpeakUp, as well as the open source components it sits on top of, will support a robust plugin architecture to allow individuals or groups to tune, tweak, or totally overhaul the accessibility of an app.
Many of us that work in professional software development take for granted that we can choose from a large number of IDEs, editors, compilers, and any number of other tools because as professionals even seemingly small optimizations add up and make us happier worker bees. But when it comes to accessibility there’s not nearly as many options to make things just so, to get a workflow that’s just for you, just for your job, or hobby. It matters that when an app’s accessibility is lacking, or just not well suited to your needs, that there are options available.
In this spirit I’ve been hard at work developing several sample plugins. The one I’m happiest with right now is a plugin that provides an accessibility API for Sublime Text via it’s Python API. Sublime Text is a very popular programming text editor and a black hole for VoiceOver right now.
Here’s a recording of navigation using regular arrow keys through the Python that powers the plugin, line by line, along with the relevant Python file for comparison. You’ll hear sequential pops indicating leading indentation level and marked up output that includes all the control characters a programmer would care about.
The specifics are subject to change, but there’s so much potential to make developer tools accessible and widen the community of people who can participate in building software on and for Apple platforms.
Stay tuned
Until I get a proper website up and running for the project, this will be the spot to watch for updates, which you should expect to see regularly going forward.
-
SPI is apple jargon (it can mean other things in other contexts) for private API, for internal use, by first party apple software. it doesn’t have the same compatibility guarantees of published API. ↩
-
The number of blind Cocoa developers is relatively small considering the huge popularity of iOS among blind smartphone users. this is largely a reflection of the very poor state of developer tool accessibility. ↩