Great post. I spent a while thinking about some of the good points you made. My friends often tell me I have a developer-centric perspective – and they're right. One of the responses I got to the tweet you cite above was, essentially, "well, not everyone is a developer". That's fine, but I still think people can do more than just complain.
What triggered the tweet you cited was noticing a number of people posting to the WebAIM discussion list about how bad Bootstrap's accessibility is. One person also posted a link to a lengthy blog post detailing some of Bootstrap's accessibility shortcomings. Based on the content, the author of the post obviously had both accessibility knowledge and development experience and it left me wondering: Why the hell would you spend time authoring such a detailed blog post rather than submitting issue reports over in Bootstrap's issue tracker in Github? At least by logging issues, the contributors to Bootstrap will be made aware of the problem. It isn't like Mark and Jacob troll around the web looking for blog posts about Bootstrap. In other words, a blog post has around 0-1% probability of improving the user experience for people who land on a site that uses Bootstrap. Logging issues in their issue tracker has a significantly higher chance of improving user experience. Contributing code has 100% chance.
I appreciate the point you and others make about "why should we be the ones fixing people's stuff? Why can't they do it right in the first place?" The unfortunate reality is: they can't. For many developers, accessibility isn't even on their radar. For others, they're aware of accessibility but really don't know what to do or how to do it. As a case-in-point, I recently spent some time on-site with a client in San Francisco. During downtime and during lunches, one of their developers asked me a lot of questions about how to do different things accessibly. I thought it was awesome and wished I had more time to answer more questions, but it highlights my point that developers just don't know this stuff. I find it extremely rare for people to develop inaccessible software because they don't give a shit. In my experience it is mostly ignorance.
So what's the answer? How do we improve accessibility in the short term? How do we ensure future work is accessible? Bitching from the sidelines isn't going to do it. It doesn't solve problems and may actually delay finding a solution. But, if we can educate, mentor, and demonstrate, we can make changes happen. Does that have to be via Pull Requests? No. But it has to be something better than simple bitching.
I know my rant is a bit heavy-handed, but I also wanted it to balance against developers who feel vindicated that someone else should fix a problem on their behalf.
I agree that detailed blog posts that aren't used to engage the developer of the broken tool are just passive-aggressive whining. I've done my share, I know.
So the approach I often take is to contact the owner and explain the issue. I prefer that over bug reports because then it's not an item in a long queue. Ideally it allows me to have a dialog and pass along some knowledge.
Sometimes I am just grumpy and I don't behave quite so well.
I agree wholeheartedly that we all have to do more than bitching. I think anyone who finds an issue needs to make an effort to report it and explain it. Those who receive it need to be more accommodating of different ability and take what free advice they can get.
In all of this, we'd all be better served if we could get our ego out of the way.
The magical talisman "open source" does not abrogate corporate responsibility to create UI that is usable by all. I spend a good deal of my personal time working with browser vendors to identify and fix bugs and contributing to open source software projects. I also sometimes write about the failings of corporations to serve their users in the products they develop (some of which are open source), regardless of ability. Both have their place in making stuff better. Characterizing the writing about issues with corporate culture and how that negatively effects the quality, accessibility and usability of a software product as 'whining' and 'bitching' is wrongheaded.
I was directly involved with OS projects for over a decade. At one point, a major OS CMS project invited me on board *specifically* to make the system accessible (both front and back end). After a year of code re-writing, providing proof of concepts, fixes, suggestions, education, etc, the vast majority of suggestions went ignored. The team said "if people want accessibility, they can build a 3rd part add-on".
I also provided feedback on a lot of other projects. Talking to core team folks at tech conferences, interacting on forums, emails, etc. Even giving bits of code to change. No great success there either. Some bug fixes that were lodged as far back as 2008 were never implemented (not the suggested solution, nor another solution to the problem).
But after giving so much of myself to FOSS, and getting nearly no buy-in from developers and site owners, I'm with Adrian – I am not giving it away for free anymore. Well, that's not quite right: I still help people who ask me and who have shown that I won't be wasting my time.
I gave a talk to Confoo in Montreal a few years ago that covered some of these issues = "Accessibility: No Rights without Responsibilies" http://incl.ca/accessibility-no-rights-without-responsibilities/
Now, I'll write a blog post, or write a tweet, bring it to the attention of the people in charge, and that's the end of it.
And it does work. @eonetimepieces makes wrist watches that can be used both by sighted and blind users. Their current website is a horror of parralax design that is unusable. A couple tweets at them and they inform me they are redesigning the site from the ground up, involving accessibility folks in the process. So now, I wait and see what they come up with.
It isn't about funding. It is about making things better. My point is that given the array of things that can make a product better, what will make that happen?
1. Complaining on Twitter? No
2. Complaining on WebAIM? No
3. Complaining on a blog post? No
4. Creating a detailed and clear issue report? Probably
5. Contributing code? Absolutely
I agree with your comments on corporate funding, but it only works if the people doing the funding make accessibility a priority. You can see this in action with IBM's involvement in Dojo. But that's not always the case. Ignorance, not malice, is the enemy here.
My basic premise remains: If someone is going to expend the energy to complain, the least they can do is expend that energy in a communication channel that is likely to lead to change.
I would suggest that both twitter and blog posts can be an effective method of getting messages across that lead to change. I say this as I know that both have worked to bring pressure to bear in the past. Characterising critical feedback to organizations and development leads responsible for 'open source' projects as 'complaining' is casting in a totally negative light. I do not disagree that getting one's hands dirty is an essential part of contributing, but it is not the only legitimate or useful way.
Karl, as my previous comment shows, I have lost faith that even contributing code or providing detailed and clear issues will get things resolved. It takes MUCH less effort to tweet or blog.