I pushed out an update today to the Edge Inspect Chrome Extension that mainly included a couple of localization tweaks and adding accessibility tags to the extension. Given that Edge Inspect is primarily a tool for designers, we had some discussion about if this was even necessary. I don’t know if I have anything new to say on the subject, but I thought it was worth writing about.
I’ll preface by saying that I’m not the guy to talk to about accessibility and your content. I’ve never given it much thought before, and I’m pretty sure what you’re reading right now doesn’t give you much in the way of accessibility features unless it came baked into the theme already. In fact when I typed that I had to go back and set the title of that link I posted earlier because I skipped that bit. In short, I’m probably part of the problem in the first place. I know that accessibility doesn’t mean “usable by the blind” but I’m probably not getting even that right.
So when the question of adding accessibility tags to Edge Inspect came up, I was one of the first to say “It’s a visual design tool. It’s not something you can use if you’re blind.” The discussion went back and forth, and ultimately we decided to go ahead and do the work. Partially on the strength of our product owner, who felt strongly that we should do it as a matter of principle, and partially because the company has a dedicated team of people willing to do a lot of the work for us. Most of the updates to the extension weren’t done by anyone on the team. It’s hard to say no to free work, especially when it’s really well done.
But the conversation in general forced me to challenge a fundamental assumption I’d made about the product, and in a way that really clicked with changes I’ve been trying to make in how I approach everything. Like most of us I guess, I used to think I could get to the right solution if I thought things through hard enough. I’ve come around to the notion that really the only way to get to a good solution is to test an assumption. In other words there is either stuff I’ve validated, or stuff I haven’t finished testing yet.
And in this context, I’d assumed that Edge Inspect wouldn’t be used by the blind, and never bothered to test that assumption. Further, we’d kinda made it impossible to test the assumption by not including accessibility in “those things we do along the way rather than bolting them on at the end.”
So I guess there were two lessons really. The first is that we were a little backwards on our thinking. We were saying “It’s a visual design tool, therefore no blind users” when we probably should have been saying “Users could be blind, how can we make this design tool useful to them.” And the second is if we’d been thinking that way all along, we wouldn’t have needed to try and bolt the work on at the end.
Will it make any difference to our users, downloads, market impact, adoption rate or revenue? I dunno. But I’m pretty sure if we don’t test things like this, we’d never really know for sure.
Note: Edited to add a link to the accessibility team who did the work for us. If you’d like to learn more about the company’s accessibility team, you can read more about them at http://www.adobe.com/accessibility