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).
