This has been under my skin for a while, and while I would regret pissing anyone off by writing it, I do think that it needs saying. If there are aspects of this which I'm missing because they haven't been shared then so be it, but if you deny someone all of the information or circumstances then you forfeit the right to be upset when they reach erroneous but logical conclusions based on the data they do have.
There's a certain group of app developers who have been doing lots for Android accessibility in the last few months. The work they've done is commendable, and I'm glad that someone else is developing in the Android accessibility space. But while I generally like their results, I take serious issue with their methods.
In July they released an accessible email client based on an existing open source solution, K9. The app they forked is itself a fork of Android's stock email app, adding lots of features for power users and others wishing that the stock client would be as featureful as the Gmail one. The problems? Two-fold.
First, they didn't actually work with the open source K9 community. Instead, they created their own ivory tower, worked in private then released their work as a separate product. While it was open source, there was no version control system, no issue tracker… Basically, contributing to their separate walled garden was about as painful as it could have been short of them simply not making the source available at all.
Then, when I did contact them privately, pointing out a usability issue that existed both in their own fork and in the initial K9 upstream, I was met with utter silence. No information on where to send my patch or even if it was welcome.
I wasn't whining about something not working like I thought it should. I was pointing out what I believed to be a fairly serious usability issue and providing a solution. But no one seemed to care…
No one from the forked project, that is. I next submitted the patch upstream to the K9 client itself, thinking that the patches would eventually work their way into a future “K9 for the blind” version. By way of contrast, the K9 developers were happy to accept my patches, seeming quite enthusiastic for their client to be as accessible to blind users as possible. I was promptly emailed by one of the project's leads expressing concerns about the use of the trademark symbol for K9 on “my” website…because, you know, if I was contacting him about these changes then this new version of K9 had to be my own project, right? I promptly replied, stating that this wasn't in fact the case. I was not responsible for the fork, but was simply contributing to people who welcomed my help and valued my work. I also urged him to try reconciling the forks so that there didn't need to be yet another separate but equal app for the blind, and unlike with me, he apparently did get a response (though it shouldn't have been his responsibility to advocate for this outcome.) The accessibility changes now reside in K9's trunk, but to my knowledge there was never an announcement that soon the official K9 app would be accessible if it isn't already.
This isn't the only time I've had this experience. Another app was recently released, an accessible web browser. I was excited to contribute to this, as I develop lots of web apps and wanted a way to use them on my phone. Once again, however, I was met with silence when I offered to submit a patch. Yet when I pointed out a fairly major bug, a fix was pushed a few hours later. So it clearly isn't that they aren't listening, just that they don't seem to want others to actually make their products better.
Sure, I can fork. But I really don't have the time to maintain yet another project that will by and large play catch-up with someone else's work. What would be far better is for them to capitalize on the advantages of open source and work with the communities they wish to help.
Compare this to just about every other open source project out there. Thus far I've contributed accessibility improvements to several open source projects. Everyone seems quite enthusiastic about accepting most of my patches, appearing grateful that someone is doing this accessibility work for them rather than simply telling them what they must do.
My tangentially-related gripe is with Google themselves. Their open source accessibility development is mostly done in secret. Upgrades to their apps aren't usually accompanied with changelogs unless someone requests to know what's new, and sometimes even that isn't enough. Their Subversion repository, while more or less up-to-date, rarely gives indications of what is new, instead consisting of lobs of unrelated changes. Obviously work is happening behind closed doors, but even the normal Android open source project produces more granular changesets. It's like the accessibility team has decided to cloister themselves in an ivory tower. And don't bother asking what's new and upcoming, because you won't get an answer, and all you can do is hope that there actually is something going on behind those walls.
So how is this secrecy different from Android? We don't know for sure what is coming in the next version, other than a few teaser blog posts made around the time of Google I/O. Simply this. Accessibility should not be your killer feature in the way that tethering, JIT or anything else is. When an able-bodied user upgrades to a newer Android, they take it for granted that they're able to read their screen. Imagine how silly it would be if release notes touted that as a feature? “Version 3.0. Now you can actually read webpages!” When Apple's iPhone dropped calls, Antennagate made them a huge joke when everyone expected their phones to, you know, actually make calls, and there was a fix made available rather quickly. Yet we're silently hanging on hoping that a feature almost as essential will be made available to us, but because there aren't millions of blind people asking for answers, we'll be treated like second class citizens while hoping that our web access will eventually become usable.
Accessibility is not a feature, just as a functional phone antenna isn't a feature. It is a design element, and being secretive about it makes no sense. Even one of Google's accessibility engineers agrees that accessibility shouldn't be a secret, but I guess that only applies to others and not to Google itself.
So I've described the situation for long enough. Why does it bother me?
First, it's wasteful and inefficient. I'm writing an Android screen reader and an accessible navigation app. These apps are each rapidly evolving, and not because they don't meet the specifications spelled out in some requirements document somewhere. If you're stuck developing apps to the bullet points collected in a requirements gathering phase then I pity you and empathize, but I gather requirements every time I leave my front door, running Spiel and guided by Hermes. I'm gathering requirements when I arrive back home and recall just how each worked well and fell short while I was out and about. And generally I'm working to fix those bugs as soon as I can. For instance, yesterday I discovered a bug or two while heading out to meet a friend for lunch–actually using something rather than sitting behind closed doors and filtering through focus groups–and the fixes to said bugs were tested and committed mere hours later. If you're stuck behind the need to develop code in a less agile manner, then why wouldn't you want contributions from those actually using your work in real situations? Hell, I wish more people contributed to Spiel or Hermes development, and even if their code wasn't quite where I wanted it, I'd happily work with them in the hopes that they'd be future contributors.
Second, it just feels like a slap in the face. I'll grant that this is my own interpretation of things, but when my contributions to other open source projects are accepted but aren't when said projects are accessibility related, I can't help but feel that I'm “just” a user and not worth considering, even though I'm taking time to learn someone's work, use it in real settings and put valuable time into improving it. It's as if I'm not a part of their focus group or engineering team, or I'm not part of their study subjects, and because of that, I'm lesser. Or it's as if I'm one of the charity cases they're out to help, and because of that, I can't possibly help back.
So let's tear down this fucking accessibility ivory tower. You don't have to throw the gates wide and accept everyone's contribution, but don't treat those of us who care enough about your work to strive at improving it as if we're second class citizens. Android is at least nominally open source, so start capitalizing on its advantages to make a better accessibility experience rather than simply discouraging contributions with silence and closed process. If I wanted that then I'd just switch to the iPhone and take what Apple gave me.
I do want to close on a positive note. While I've pounded various groups for doing it wrong, there is one group that I feel truly gets it, and that is the University of Washington. They've developed a number of accessibility apps, some of which I've played with, and when I found that their OCR app didn't work with my phone's multi-stage camera button, I spent an hour or two putting together a patch that made it work. Emailing the contact address on their site, I expected that once again I'd not get a response, but was pleasantly surprised. Not only did I get one, but my email was forwarded to the student working on the project, and my patch was greeted with enthusiasm. He even wondered if I could help with future development. Unfortunately I really don't have the time to take on other projects, which is why I'm not forking those that don't want my contributions, but he also answered my technical questions about the project's direction and choice of back-end technologies. The whole experience felt vastly more welcoming, and if I have time to contribute to others' projects in the future, I likely will invest that time where I've been made to feel welcome rather than where I haven't.
So if you're working on the next big thing in accessibility, and are planning to open source it, read The Cathedral and the Bazaar. Even if you don't agree with everything, release early and often. There was a version of Spiel available mere weeks after I started working on it, even though it was highly unusable, in the theory that anyone who cared enough about such an effort could download it and help make it better. If you remain in your ivory tower building your cathedral, then you're engaged in inefficient processes that will just hurt everyone who is striving for practical accessibility solutions rather than theoretical and brittle ones.
If you're one of the groups or individuals about whom I've ranted, note that I only do so because I'm passionate enough about your work to advocate for its improvement. I could be outside enjoying a nice, sunny day, but instead I'm giving an hour or so of my time toward writing something that I hope will make some difference. And considering Austin is in the midst of monsoon season, that I'm not out enjoying the first sunshine we've had in days right now is pretty huge.
If you'd like to improve but don't quite know how, I highly recommend this free book. It's given me lots of things to ponder when launching my own projects, and while I don't necessarily excel at them all, I do try to follow its guidance.