The Accessible Web is a Bust - Now What?

Our best efforts to make the Web readable and understandable by all users and agents is, for the most part, a bust. Efforts to integrate accessibility into the design and development culture are mostly a failure. Years of scolding and admonishing and hand-wringing have returned very little else than a small, incremental improvement as table layout wains and designers embrace CSS. Despite the efforts of the small cadre of dedicated experts, the sheer number of flawed new documents perception that the Web is a bad place to be with serious disabilities.

Accessible design is a moving target. New media and technologies require new responses for accessibility. But what most developers instinctively feel about integrating accessibility in their work is probably true, if only it were testable - that design for accessibility can be a drag on innovation, that their personal and professional interests understandably (if not nobly) lie with innovation more than supporting policy. (I came to this conclusion at last year's OSCON after a veteran hacker at Yahoo ridiculed me for questioning the accessibility of his AJAX widget - “duuude, ... it's a HACK!“)

We all agree that the goals of accessibility are good: 1) I doubt anyone will argue that it's not the right thing to do. In fact, 2) even the coldest economic analysis will conclude that benefits exceed costs, especially when the risks of litigation are factored in. On the other hand, there's no point in continuing a failed strategy of training people who are to take the extra time and care to make a document accessible. So, let's try something else.

Let's start with a question. How does an institution maintain a consistent and professional appearance through it's print media; in, for example, its official communications, brochures and magazines? How does it make sense of its budget and communicate the current financial condition to administrators? By using standard templates for software, refined over the years by testing and feedback. Staff don't make decisions on design and placement of trademarks, or the layout of regular budget reports - those decisions are hidden in the tools they use.

Yet, we take the standard approach of training designers and developers to make design decisions intended to make documents accessible. Tools like Dreamweaver build in useful features that are close at hand, like validators and code completion, but most developers don't use them for several reasons. Staff still have to make decisions without a foundation of knowledge rooted in experience or empathy. Clearly, we can't look to the old-school tools for solutions.

There are at least two things that are missing from the old methods and tools of Web publishing. One is a point in the publishing cycle where specialized knowledge is applied to a review of the accessibility of the document. What I am suggesting here can only happen with a tool that supports collaborative editing and work flow. And, at some point in the workflow has to be a person that can review content for accessibility. Those capabilities define the core requirements of content management systems.

Second is a lack of automation to apply the available markup to augment the accessibility of particular content types. For example, there is semantic markup available to make data tables unambiguously readable and understandable; it's right there in the HTML4.01/XHTML specification. But I rarely find it in the wild and then only see it used in scholarly articles which must be readable by machine agents like CiteSeer. More common on a relative basis, but still rare, are examples of the special markup that makes forms accessible, and old tools do indeed support it, if only most developers understood its application. Automation, followed by a quality check in the workflow could do much to improve accessibility. An important question is who in the workflow reviews content and the occasional change in templates. If you agree with an earlier post on changing roles and specialization in web publishing (The Strange Case of the Disappearing Webmaster), it could well be a specialist.

An interesting development is a set of new standards (WAI-ARIA: Accessible Rich Internet Applications) that could vastly improve accessibility. ARIA aims to embed very detailed metadata and state data into the content of the document. It would not only identify and distinguish content areas from navigation widgets, news boxes, headers and footers (ARIA “Roles”), but would indicate whether navigation trees are open or closed, and whether AJAX-driven boxes have updated information (ARIA “States”). This, folks, is a major advancement; it also involves extremely complex markup and a significant learning curve. It will only happen if ARIA markup is automated.

I will keep developing these ideas and provide some resources so that you can decide for yourself.