Looking back to the time when the concept of web accessibility entered legislation and consequently the discursive arena, the primary issues surrounded retrospective reworking of corporate websites to make them accessible. This had two long lasting effects that still continue to define the way we view accessibility today.
- It separated accessibility from usability, because ‘usable’ web content already existed for the majority audience, i.e. sighted users who had no trouble using human interface devices like mice.
- It embedded the idea that accessibility is expensive and needs a business case, because it was expensive to redesign and change existing interfaces and/or to write conversion code for screen readers to allow user access.
The impact of this has been two-fold – I find that people generally think accessibility involves coding complexity that is beyond them; and then often where it is applied, accessibility is often implemented simply to pass validation, rather than with the aim of making the interface more usable.
An analogy I often use involves a maze. If I had a maze and put ramps at the entrance and exit, I could argue that the maze was accessible, and my argument would be supported in court. I could take someone in a wheelchair, blindfold them and get them into the maze with no trouble. What are the odds they would ever get out?
On the other hand, if I also built a path straight through the maze from entrance to exit, I could pretty much guarantee they would exit the other end with little trouble. In fact I would also be significantly reducing the amount of time that sighted, mobile people got through the maze too. That, in essence, is the difference between accessibility for accessibility’s sake, and accessibility to improve usability.
Now which one do you think would be more expensive and difficult to implement – designing the space from scratch with a direct path through it, or trying to go back and break down walls and structures to put the path in after the space has already been built?
In reality accessibility is therefore simply another way of describing usability for people with access inhibited by visual, cognitive or motor impairments. If you think the two are separate, you are missing the point altogether and can safely assume that whatever you are building will be an exercise in technicality, rather anything useful for your wider user base.
The key then is to think in terms of usability, and plan for the experience of a wider range of users and browsing technologies when designing your website or software interface, and you will find that you have built in accessibility without trying, and for no significant extra cost.