Learn to Do It Yourself
Often when I identify a valid technical (typically accessibility) issue with a site, tool, or library and get a response of just make a pull request,
I am thrown into an apoplectic fit for which I have to apologize to my co-workers (or people at the random coffee shop or airport).
My Thesis (Rant)
I am not going to fix your arcane niche library/tool nor your single-use site that you’ll dump in a few months. That isn’t a good use of my time, and you learn nothing.
I bill for doing just that; it’s how I earn a living. Like all of you, I have many things to do besides my day job, some of which are far more important to my community or personal well-being.
I speak at conferences and write for sites not just for free, but at a cost to me in most cases (nearly all cases), specifically to teach the skills that would allow you fix the issue on your own. I do this without targeting a specific language or platform except where it most directly impacts the user (typically HTML, CSS, and vanilla JavaScript).
I am trying to identify issues and arm you to fix them, both in this case and for the rest of your career.
Asking me to fix it (hey, just make a pull request
) is a cop-out. It’s short-arming your own technical growth.
Fix it yourself.
Learn how to do it.
Carry that skill forward to future projects, enriching both your users and your career.
Take some pride in your craftsmanship by learning how to address a valid problem.
Short-arming accessibility (the vast majority of my bug reports) is why we’re inundated with inaccessible libraries and tools. It’s always someone else’s problem.
My Pedigree
I’ve been performing reviews, contributing to and building one of the first developer sites and lists, speaking, writing tutorials, articles & books and generally been offering my time and expertise for free or nearly free for almost twenty years.
As an example, when I started Print Shame it was born of frustration from developers failing to make the extra effort. Then I decided to be more constructive and wrote a number of articles, developed techniques (with cut-and-paste code), backed it up with research, and flew/drove around at my expense to present all that I learned.
If I tell you that your site doesn’t print and you suggest I can give away my time to fix it, I’ll note that I’ve already done so. In some cases I’ve spent more time educating for free than you spent building the entire project.
I’ve given back, and I continue to do so. In a way that will outlive your site or project.
Ideally, my talks and writing reach more people than one bug report. Hopefully they provide real-world context and examples for others to draw parallels to their own projects.
My Overreach
My mentor would always ask the same question when I whined that somebody wouldn’t do something I wanted. He’d ask, What are you going to do about it?
Karl Groves makes the same point, essentially, for open source projects:
When you bitch about an open source project, you're not solving anything, just making noise. Stop bitching. Start fixing.
— Karl Groves (@karlgroves) October 16, 2014Steve Faulkner pushes back:
@karlgroves 'open source' projects heavily funded by corporate $$$ should not place responsibility for #a11y on the community
— Steve Faulkner (@stevefaulkner) October 16, 2014Sometimes that applies, sometimes it doesn’t. Karl is right in his response that two thousand word blog posts aren’t even bug reports. I get that. I encourage you to read the entire Twitter thread; there are valid points on both sides, some which poke holes in my argument above (in specific cases) and some which bolster it.
There are many people who are better than I by fixing tools directly. Patrick Lauke has been stepping up and contributing accessibility fixes to Bootstrap. Marcy Sutton has done the same for Angular. Many are contributing and doing great things. Not whining, but doing.
When it comes to non-open-source projects or sites, it’s a bit more difficult to just do something. I’ve spent more time trying to get Virgin America to fix its keyboard accessibility failure than if I had been granted access to the code to remove one line of CSS. In those scenarios I am stymied.
I also know I can come off hot, like when I raised a similar issue to a buttons library. I acknowledge that when I recognize it, but in the end the issue was resolved, the developer learned something, and end users get a better experience. It can work.
My Message
If you are a developer and find an issue as part of an open source project and have the time to fix it, do as Karl suggests above and fix it.
If you don’t have the time nor inclination, help the developer with a detailed bug report. You don’t have to use the bug reporting tool, you just need to get it some attention.
If you’re a developer and you’ve had a valid issue identified, then don’t expect the person reporting the issue to fix it. It is fine to ask for help if you don’t understand the issue.
Asking the person who reported it to learn your bug tracking system is a bit much. Accept the feedback as offered, even if by Tweet (where you may be most accessible).
7 Comments
Reply Adrian,
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.
In response to . Reply Karl,
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.
To your point about Bootstrap, having watched tweets from Patrick Lauke, I am reminded of times I have wanted to code a fix but didn't have the right platform or tool-set to do so.
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.
Reply 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.
Reply Steve,
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? AbsolutelyI 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.
In response to . Reply 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.
Reply 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.
Reply 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.
Leave a Comment or Response