Re: DRAFT PROPOSAL: Conceptual relationship of WCAG to other specifications

Hi Michael,

FYI, Shawn and the EOWG are working on an introductory document
(currently) called "Interdependent Components of Web Accessibility".
  <http://www.w3.org/WAI/intro/components.html>

It is not yet stable and it is not based on the WCAG perspective of the
world but still draws a similar "big picture" of the components and
relationships you are describing.

Regards,
  Shadi


-----Original Message-----
From: w3c-wai-gl-request@w3.org On Behalf Of Michael Cooper
Sent: Thursday, March 10, 2005 02:44
To: WAI GL (E-mail)
Subject: 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/

Received on Thursday, 10 March 2005 12:02:23 UTC