Kynn's WCAG Proposal

Here's my take.

(I'm still catching up with the archives, so apologies if I go over
ground that's already been gone over before.)

_The_ most important thing that the Guidelines can ever provide are
a set of checkpoints which, if followed by a responsible web
designer, will result in increased accessibility for all users,
particularly those with special needs.

That's our mission as _I_ see it, and we need to be careful to
_not_ lose track of it.

Broad principles are very good and very useful.  They help to give
context to the checkboxes and explain why exactly things are done,
in addition to heightening awareness and providing web developers
with the ability to make their own judgment if they are encountering
new technologies or situations not covered by WCAG.

However...

I don't think they're necessary at all in a document that primarily
deals with _how to do the right thing_.  And I think that HTDTRT
(acronym for "how to do the right thing") document is of immense
value as a formalized, definitive standard for the web, and the
list of vague principles is of questionable value to what we are
trying to accomplish, by comparison.

I propose that we focus on the HTDTRT document, but that we also
create a Principles of Web Accessibility document that is published
as a W3C note and which is referred to extensively in our HTDTRT
document.  A way to visualize this -- if we look at the original
strata of the WCAG, the "techniques" were on the bottom and got
pushed out to a non-normative W3C Note.  I simply propose that we
do that with the top of the strata as well, putting the broad
principles into another Note, which is considered good and 
valuable, and which can explain the HTDTRT checkpoints, but which
is not part of that document itself.

Then we get to the HTDTRT checkpoints.  I believe that we need 
to group related checkpoints together under "strategies" as has
been suggested, and I furthermore believe that checkpoints
_must_ be technology-based.  For each group of strategies there
should be a set of HTML checkpoints, a set of CSS checkpoints,
a set of XML checkpoints, a set of SVG checkpoints, and so on.
If this means that we will need to publish an addition to the
WCAG whenever a new technology is released, then so be it -- it
may mean that we need to define WCAG itself in modules a la
modular XHTML!

Checkpoints must be specific and they must be checkable.  They
must be understandable with reference to the WCAG Principles
document and the WCAG Examples document.  (Oh, that's right,
we should drop the term "Techniques" for that document because
that's not the plainest, most straightforward term for what it
does.  WCAG Examples nee Techniques should be a set of sample
code and example which show how to meet each checkpoint.)

There's my pie-in-the-sky description of how I'd restructure
WCAG to make it easier to understand.  What do you think?



-- 
Kynn Bartlett  <kynn@idyllmtn.com>                       http://kynn.com/
Director of Accessibility, Edapta                  http://www.edapta.com/
Chief Technologist, Idyll Mountain Internet      http://www.idyllmtn.com/
AWARE Center Director                         http://www.awarecenter.org/
Vote for Liz for N. Am. ICANN Nominee!             http://kynn.com/+icann

Received on Monday, 14 August 2000 23:05:14 UTC