Web accessibility can be a bit of a mystery. If you were to ask a dozen people to define it you’d probably get a dozen different answers. What makes a website accessible may vary quite a bit from person to person. Some will key in on making the site available to all sorts of user agents like browsers, cell phones, televisions, and more. Others will respond with a focus on making sites available to disabled users — at which point they should elaborate because “disabled” is a far-reaching word. Once overheard, a person muttered that web accessibilities meant making sites for the blind; nothing more.
Well, you know what? They’re all right. The myriad disabilities, the various devices, and, yes, the blind users as well. All of it. It all counts, it all means something to somebody, and really, that seems to be the point. But before we think in terms of making anything for anyone, combining these concerns, and getting all complicated-minded, let’s step back and think this thing through. The first natural thought would be how are we going to make a website accessible, right? Or, perhaps, what features are we going to add to make the site more accessible?
This could be the first mistake. And many developers will make it. It’s a natural mistake, actually. It’s the designer that lurks within. You see, the most accessible page is easy to make. Stick to text, use proper headings, paragraphs, smart navigation, and all those other elements we’ve grown to love, and put it down in a proper, valid, and semantic way. Good enough, right? Yes. But then here comes that designer in us all, and it’s the designer that’s going to screw things up. It’s the designer who’s going to put in the imagery, and do things like create a layout. It’s the designer who’ll start throwing up barriers. This is where it starts getting tricky because, ideally, we will have to start taking into consideration the needs of as many user groups and their devices as possible once this process begins. Not to make it accessible, though, but to retain the mark-up’s inherent accessibility.
We make a layout, often doing something as simple as floating a sidebar, and we begin styling things like forms, and we employ scripts, and we add imagery, and colors. We add complication. With each of these there are inherit barriers to page’s accessibility. We’re making our sites more inaccessible by way of making them something mainstream users want to see and use. Of course there are those out there that are perfectly happy with an unstyled page with no features, but this is the exception to the rule, all professional developers know this as fact, differing only in how accepting of the fact one is. Most clients don’t want to buy unstyled works from developers. No, indeed, they want great-looking sites, with tens, no hundreds, of accessibility and usability barriers. They won’t call them that, but we know better.
We often speak of adding things, features, in the name of accessibility. And it’s true, we can and do, but more often than not, these things we “add” are not to make the page accessible, but rather to break down the barriers we put up rendering it inaccessible when we made it work well and look cool. We’re not going to suggest you don’t put up these barriers then break them down with features, but thinking about it this way may make the process a little more understandable to some. When thinking in this light a good developer can analyze everything added to the page, identify its inherent barriers, and find features or work-arounds to make sure they don’t impede disabled users. (For the record, by disabled we don’t mean it the way you may be thinking. Anything can be a disability: lousy equipment, slow connection, a handicap… it can all be classified as a user disability. It all counts.)
If you would like, you may
post View comments on “Breaking Barriers” on Mike Cherim’s weblog.