January 18, 2007

A Vision Thing

People are often amazed when they learn this: websites can be "read" by blind people. The technology exists today. The only catch is that websites must be built in a way that makes their content "accessible." That's the bad news. The good news is that with few exceptions the methods involved are straightforward, well-documented, and easy to master. The core techniques add little time to development, and in many cases provide benefits beyond improved accessibility (for example, better usability and better search engine optimization).

Sounds great, right? Most developers must be doing this, right? Wrong. Few websites (one in a thousand?) meet even the lowest level of accessibility compliance (i.e., Section 508 or WCAG Priority 1). Moreover, few web developers know much about accessibility, or even care to know. There are many reasons for this—over-reliance on print-derived design practices, overuse of inaccessible technologies like Flash, poor support by application developers, and of course a fair share of ignorance and laziness—but in the end, it comes down to a vision thing.

A Web for Everyone

Few developers, when asked to describe their vision of the web, would begin, as does the W3C, with the idea of "a web for everyone." (The W3C's second long-term goal—"a web on everything," meaning on all devices, would receive little mention as well, but that's another story.) In fact, relatively few web developers think seriously about the medium at all. It's enough to deal with the problems inherent in finding clients and making those clients happy than to start worrying about pie-in-the-sky abstractions like "a web for everyone." And anyway, few clients expect their sites to be accessible (usable, perhaps, but not accessible), so why bother?

Here I have no argument—or rather, I've learned not to argue. You can't convince people to care about an abstraction. The best you can do is make a business case for what you believe. People will generally listen to business cases.

When I say "people," I mean clients. I rarely discuss accessibility with other developers, as I'm loath to tell anyone, however obliquely, how to do their job. Also, I often find such conversations depressing. Clients are one thing (why should they know anything about accessibility?), but the lack of knowledge about accessibility among developers seems almost shameful, particularly when it derives from a policy of giving clients what they want, regardless of the consequences for the website or the people using it.

Those are strong words, and to some degree they're unfair. Four years ago I was building inaccessible websites. Everyone was, pretty much. Then I read Mark Pilgrim's Dive into Accessibility, and I got religion. Now, four years later, it's a bit too easy for me to call nonbelievers heathens, or as I did above, shameless hacks. The truth is more complex.

What's needed, I think, is some old-fashioned education and leadership. However, as much as I believe in a web for everyone (as well as a web on every device), and as much as I believe that this vision would benefit everyone, including website owners, I'll never be an accessibility evangelist. What I will be, though, and what I am, is someone who builds accessible websites.

No Lid Fits Every Pot

I have a simple policy: I don't work on sites that fail to meet a minimal level of accessibility (specifically, Section 508 and WCAG Priority 1). Now, I don't expect this policy to change the world or make a difference to anyone who isn't already sold on accessibility, but it does make a difference to me, in that I get to do what I love and what I believe in doing.

It also makes for some interesting conversations with prospective clients. Most react well, particularly when told of the benefits for themselves and their visitors. However, I'm careful to avoid the hard sell, and I don't downplay the downsides.

The key moment comes when I outline what I've found to be the most common accessibility "gotchas":

• Unannounced new windows, including pop-ups
• Using color only to indicate inline links
• Poor contrast between text and background colors
• Using Javascript for core functionality (e.g., dropdown menus)

This is basically a short list of what clients can't have if they work with me. Of course it's also a list of what they shouldn't have, as I see it, but I don't expect everyone to look at it that way.

I lose—or turn down—about a quarter of all prospective clients on this basis. However, I don't really think of these as losses; they're more like poor fits. My policy helps me identify the right people to work with, and vice versa. In other words, every pot has a lid, but no lid fits every pot.

Not every web developer is in a position to turn down potential work because of a principle. However, I've learned that regardless of what people think about accessibility, they invariably respect the motivation behind the principle, which is to do the work I love.

I recommend it.

Published in Accessibility, Business, Clients