“Accessible,” in the provenance of the internet, usually means “screen-readable.” That is, we consider a website “accessible” if it is decently navigable by audio alone. We rarely test this, instead relying on the W3C Web Content Accessibility Guidelines (WCAG) or Section 508 of the Rehabilitation Act of 1973, a 35-year-old standard.
The Yoke of Accessibility
But we usually view these guidelines as a burden: they limit our creativity; take our most brilliant ideas and strip off the polish. Typical accessibility checks are run towards the end of the design process, and we go back and grudgingly fix the errors, unhappy but acquiescing so we get paid.
This definition of “accessible” assumes that every person is either perfectly capable, or completely blind. (Or deaf, I suppose.) In either case, we rarely assume readers will do things like change the text size or the page colors, or turn off background images or stylesheets all together. But these are all common practice for readers with a whole range of needs, from those with incomplete visual impairment to those who are easily distracted by excessive color to those who may simply like to customize things.
“Universal” has a sense of “everywhere,” and I also want to include “everyone,” and “everywhen.” (“All the time,” but that would have broken the rhythm I had going.)
The key to implementing “universal accessibility” is to begin at the beginning, and not finish until the end. We all know the changes we’ll have to make later, so start your design process with these in mind.
The benefit to us as designers is that our final product won’t feel like a bastardized version of our original concept. By incorporating accessibility from the beginning, we won’t feel like we had to “hack” our own design to make it work. It also saves us time in that step, when we may be too tired or too frustrated to re-implement everything accessibly.
Another concern of “accessibility” is the ever-increasing stable of web-capable devices. From iPods to Smartphones to Wiis, a wide range of devices with various support for standards can all access your sites. CSS supports differentiated styles, but not all devices do. Fortunately, if you’re out of other ideas, server-side solutions could ensure that broswers see the right code.
But the real idea of “accessibility” is that everyone, regardless of ability, can access your content.
We need to widen our vision and consider all the impairments, not just blindness. It’s a simple numbers game: far more people have partial visual impairments than complete, far more people have learning or cognitive disabilities, far more access the internet from their phones. If we cater to the blind, surely we should cater to these people as well.
The Next Step
In the next article, I will talk about ways to assess a site for this “universal accessibility.” For the most part, these are simple steps that only take a few seconds to understand, and, with forethought, literally no time time to implement. They’re not perfect, or complete, but I hope to get people thinking about their own ways to build accessible sites from the ground up without sacrificing their designs and while improving their sites for everyone.
Read the rest of the series:
- Universal Accessibility
- What is Universal Accessibility? (Part One in a Trilogy)
- Assessing Accessibility (Part Two in a Trilogy)
- Building Accessible Sites (Part Three in a Trilogy)
Sorry this was so late. I’ve been busy and in the middle decided to alter the direction of the piece. Hopefully the next in the series will come sooner.