DRAFT PROPOSAL: Conceptual relationship of WCAG to other specifications

During the face to face last week we grappled with a number of issues about what should go into guidelines, what should go into techniques, what should we say at either level about "until user agents" type issues, etc. As the discussion progressed, it seemed clear to me that WCAG operates within a certain context. Many pieces of that context exist, and I think for the most part we agree on what this context is, but we have not spelled it out and used it to focus and limit our work. Consequently there has been a lot of confusion and a tendency to try to make WCAG stand in for the entire context, rather than restrict itself to a set of authoring guidelines.

This is a very rough description of the way I am seeing things right now. There are a lot of details to fill in, some of which probably need to be explored for people to determine if it works or not. I presented this to the Protocols and Formats group last Thursday, and during that discussion a different proposal emerged, which I said I would also work out for comparison. For the moment though I'm just presenting my initial proposal. I will refer to a number of documents or categories of documents. It is important to point out and acknowledge that much of this material already exists, at WAI and elsewhere. I am not proposing that we take on work of filling in any gaps or consolidating resources, nor do I here provide an inventory of what may be where. I simply want to create a hypothetical, conceptual relationship between these documents and use it to help direct and constrain our work.

I have attached a graphical presentation of what I am describing below. This is called "windowdrawing" because last week I was attempting to present this to a small group of people in invisible ink (hand-waving) on a window in the hotel where we were meeting.

Conceptually, we work within a context of a definition for accessibility, what I am calling a Functional Specification for accessibility. This describes what a user should be able to experience for the content to be accessible to them. For most of the time I have been involved in WCAG, I saw WCAG as fulfilling that role. However, now I believe that this functional spec should exist separately - there should be a universal definition of accessibility that everything else supports. I don't believe such a document exists although pieces of it are in many places.

In order to ensure that content meet the functional requirements for accessibility, a number of other things need to exist: specifications that provide accessibility features, user agents that take advantage of those accessibility features, content authoring guidelines that direct authors how to create content meeting these requirements, and authoring tools to assist authors in their task. There would then exist specifications at this second level describing how implementations of each of those four roles should accomplish their task (and WAI has created many of those resources). WCAG obviously is the content authoring guidelines side. It's important here to note that WCAG exists on an equal basis with those other sets of guidelines, and all of them work together to support the higher-level functional specification for accessibility. 

At the third level is techniques. Conceptually there would be (and to some extent, are) techniques for each of the guidelines at the second level, and for each of the guidelines the techniques can be categorized in the way I will describe for WCAG techniques. The drawing and this narrative only describe WCAG techniques as an example. As we have been envisioning things, techniques describe ways to implement the guidelines in support of accessibility. 

There are a few categories of techniques. Perfect world techniques describe what should be done if the world were perfect. In the case of WCAG, this is techniques authors should follow if specifications define accessibility properly, user agents render content properly, and authoring tools assist authors properly. Some perfect world techniques actually are useful now, so it's useful to expect authors to follow them; others will only be useful when the landscape changes, so while we would like to instruct authors to follow them, there is no actual benefit to users to follow those techniques today. Nevertheless we document those techniques in anticipation of future usefulness.

In addition to perfect world techniques, there are techniques that we need to create for our imperfect world. Some of these techniques are requirements we make on authors, that we don't feel we should actually have to, because user agents don't support something we think they should, or because the technology being used doesn't provide a particular access feature. Finally there are techniques we create to resolve not just lack of implementation but broken implementation. For example, if following an accessibility authoring technique causes negative benefit because of poor user agent implementation, we could create a technique for authors to redress that issue.

So that's the proposal. Already I see changes I would make to it, and as I said there exists an alternate version that I have also promised to describe in high level. Once again, I am not recommending we create this accessibility universe that I have just described. But if we on this universe as a conceptual framework, I think it will help us to determine how to resolve many of the difficulties we have been facing. For one thing, many of the aspects of our guidelines that are really part of a functional definition of accessibility could be moved out. And when we debate whether to create a certain guideline, we can ask ourselves whether it is truly a content authoring requirement, or whether it is something else and therefore doesn't belong in our document. For techniques, this gives us a way to create techniques that don't specifically tie to content authoring guidelines. Our "repair techniques" can be justified in terms of broken user agent implementation rather than in terms of an authoring guideline that we shouldn't have to create (and wouldn't if user agents behaved properly). This can help us at both the guidelines and techniques level to avoid the temptation to provide "until user agents" style stuff, an issue that is our constant nemesis.

I hope this isn't too difficult to read - I had to write it out pretty quickly. If there is interest in this I can work with people to explore some of the consequences this structure would have, as well as to explore different structures focused on the same goal of clarifying our conceptual framework to facilitate decision making.

Michael

--- Signature ---

Michael Cooper
Accessibility Product Manager, Watchfire
1 Hines Rd Suite 200, Kanata, ON  K2K 3C7  Canada
Tel: +1 (613) 599-3888 x4019
Fax: +1 (613) 599-4661
Email: michaelc@watchfire.com
Web: http://www.watchfire.com/