Accessibility is one of those areas that most software engineers and product teams seem to have little or no knowledge of. When it is brought to the attention of the decision makers, I’ve heard all too often, “We’ll do that if we have time at the end of the project” or, “What is that? Why do I care about it?” What’s worse, is that in the eyes of many companies and project leads, they can easily rationalize to themselves why accessibility shouldn’t be included in the development cycle:
“Why would a blind person own a touch screen device?”
“I think you’re solving a problem that doesn’t exist.”
“That’s not our target demographic.”
“I can’t see how this would improve our App Store ratings.”
“QA doesn’t know how to test it.”
It’s really sad. Especially when Apple has made it so incredibly simple for us to implement. They’ve done all they heavy lifting for us and simply said, “Carry the baton across the finish line. Please.” And most of us drop the baton.
Honestly, it takes minutes to make your application accessible to a population that all too often gets the shaft. I am a fan of Matt Gemmell. Everything from his tweets to his blog. Even if you’re not a fan, I implore you to read just one article. It’ll make you a better software engineer, and you’ll make your software usable to an audience that seems to lack a voice.
See Matt Legend Gemmell’s article:
Must-read for developers. Both a good high-level overview of what accessibility really means and who it helps, and a technical overview of how iOS developers can take advantage of it. iOS is simply leaps and bounds ahead of the competition in accessibility.