One routine challenge in being an accessible web developer is convincing clients of the necessity of certain features you’ve implemented. I don’t sell my services specifically on the grounds of accessibility; accessibility is simply a feature of my web sites. As a result, not every client is even aware when the project starts that they’re going to end up with an accessible web site.

I don’t make an issue of it. I just make it happen.

However, this does frequently result in conversations during the project concerning the way things have been done. The fact that I’ve added skiplinks to the top of the page is one of the most frequently challenged decisions — largely, because it’s the most visible feature.

It’s rarely a problem once I’ve explained the reasoning behind it; only very rarely do I hear any complaints echoing the myth that “their site isn’t visited by the disabled.” Nevertheless, it continuously reinforces my impression that accessibility simply isn’t part of the planning for most web site owners.

It’s possibly true that I’m not really helping matters by failing to raise the subject early on. But I really don’t feel that site owners should have to take responsibility for worrying about the accessibility of their sites — the best situation I can imagine is that the average web designer would put together a reasonably accessible design by routine, rather than having that kind of extra care be primarily the purview of specialized “expert” developers.

The world of best-practice, standards-based web design is pretty small. Although there are many highly vocal advocates for web standards and accessibility, the majority of firms and independent designers seem to still be locked pretty firmly in a more primitive world of web development.

Clients drive the market. If the vast majority of companies looking for web development explicitly required standards compliance and accessibility, I’d like to believe that this would become a standard practice. I’m not certain that this is true, however. There’s a fallacious understanding of accessibility that perceives it as an “add-on” to a website. It’s very easy to imagine a contract with a simple check box specifying “Accessibility: +20% of total cost.” That’s a great way to discourage accessible web design: charge extra.

Accessibility doesn’t really require much extra work. In fact, the smart design and layout principles which are involved in much accessible web design actually makes it easier to implement than some design techniques (tables, for example). Selling accessibility as an add-on feature is simply a matter of taking advantage of the ignorance of the customer.

I’m not saying that there actually is a rash of companies handling accessibility this way; but they certainly exist. Some of them implement accessibility features in an manner which is actually very poor practice, by taking their existing design and throwing in accesskeys, tabindex, and/or a Javascript-based text resizing widget. This is less an issue of taking advantage of the consumer as it is one of developer ignorance.

The reason for advocacy of best practice accessibility techniques is to educate: educate developers so that they know how they can implement accessibility in the most consistent and efficient manner, and educate consumers so they know that accessibility is something they should be able to expect in their new website.

When an accessibility feature is challenged on a site I’m building, I’ll go to whatever lengths are necessary to educate the client about what value this feature provides and what barriers are created in it’s absence. If I can’t sufficiently justify it; it’ll go. Maybe I need to reconsider it’s value myself. But I’m not going to sell accessibility. I’m perfectly happy building an accessible web site without the client ever even being aware of the issue.