The Magic Wand of Accessibility

I can’t count the number of times someone has come to me with a nearly completed document, app or website wanting me to quickly “make it accessible”. They seem to think that I will have some special accessibility dust I can sprinkle on it, or a magic accessibility wand that will just tweak everything right.

The bad news is that no such magic wand exists — if it existed, and I owned it, I would already be rich from commoditizing it. The really bad news is that, depending on how complex the implementation of your document, website or application is, making it accessible after it is completed may be as hard as tearing it down and starting over — though sometimes you get lucky and it’s only major surgery.

But there is good news: it isn’t that hard to make an accessible product from scratch. You just need to have a little bit of accessibility knowledge spread through your whole team and one or two accessibility experts to handle accessible design and finding solutions to the difficult problems that arise now and again.

In this regard, accessibility isn’t any different than any other global requirement for your project: performance, usability, security, effective content, etc. With all of these, you need to design, execute and test for these properties at all stages of development, and while there may be one or two experts to focus on this requirement, it is always assumed that everyone on the team is pitching in, being mindful of it as they do their main work.

Admittedly, it takes some time to get all these pieces into place, so there has to be a practical first step to get you there, and what I would recommend as the most effective place to start is by having testers — be they full time QA, developers unit-testing their own work, or end-user acceptance testers — to start periodically performing their testing with keyboard-only input and with a screen-reader. This testing, if done throughout the project, will catch 90% of your accessibility problems.

I hope to write a longer post soon focusing on just this topic, but for now, I recommend acquiring a free screen-reader, such as NVDA on Windows, for all your testers, get them to learn only the very basics — which I’ll cover in that upcoming post — and get them to start testing with it at all stages of development. This will make the problems visible and stimulate the acquisition of accessibility knowledge and skills through your team organically and incrementally.

I’ll repeat this as the closing moral of this post:

Testing with keyboard-only input and with a screen-reader at every stage of development is the most effective way to start creating accessible products.

Advertisement