bestkungfu weblog

Accessibility is a process, not a product.

Authors and designers need to know this fact if they are to approach designing more accessible sites. It is not sufficient to rely on evaluation tools like Bobby or Page Valet or Cynthia Says to hold an author’s hand through the eerie jungle of accessibility requirements. People who design sites like this, though often well-meaning, usually generate crap, often for two reasons:

• Authors ignore non-automated tests that they would otherwise fail;
• Authors design their sites to pass the tests they are given, without understanding the underlying accessibility-related problems

Why? Well, for one thing, accessibility evaluation tools are only capable of testing for signals that a given markup technique is wrong. This is not the same as, say, the W3C HTML Validator, where the rules are hard and fast, and refer to a normative specification. And it never will be that way in accessibility: we’re not designing for a standard, or four or seven or fifteen different browsers, we are designing for users. Eyes, ears, hands, minds. Millions of them, all different.

This is the big league of user-centered design: if you fail, you didn’t just frustrate the user, you locked her out of your content. The consequences, as described by many accessibility advocates to many bean counters, can be legal in nature. But inaccessibility is a social ill, causing barriers that, while less visible to the public eye than segregated washrooms, are just as relevant and damaging to society. It is going to require more than a quick pass over the home page and a Bobby logo to solve.

I’m going to the Web Content Accessibility Guidelines Working Group face-to-face meeting in Venice this week, as we work on WCAG 2.0. What I’m hoping to say there is:

• Per-site conformance is more important than per-page conformance, and the Guidelines should reflect that.
• The Guidelines should emphasize Web design practices, rather than atomic techniques.
• Authors should be made aware of accessible design practice before they write more content, so they will take less-measurable requirements more seriously.
• “Accessibility” is not a tangible property, or a bullet point of a requirements document. It is the overall result of a concerted effort to understand and design for people with disabilities.

It’s not that much harder to turn this concept of tangible Accessibility into something deeper and more meaningful to the people who work on it. What it will take, however, is a more process-oriented document, and conformance scenarios that match the way WCAG will be implemented.

Sites should be able to create a statement of accessible design practices, with exceptions noted, and pointers to the means by which they examine their content (using an evaluation tool, by hand, etc.). This should be in a machine-readable format, so that users with disabilities will know beforehand whether adequate efforts have been made to meet their needs. Accessible design is not a grab bag.

Where the toolmakers need to step up, in my opinion, is at the publication layer. A best practice for creating accessible sites would be to use a content management system that forbids the publication of non-conforming content without peer review. This enforces the accessibility process, while granting advanced users the ability to design for the user and not the enforcer. I think this would be a great step forward for accessible design. (Not that I’m biased, being the co-editor of the Authoring Tool Accessibility Guidelines 2.0, which outlines how to implement this kind of process in authoring tools. No no. Not me.)