Re: Kynn's WCAG Proposal

Writing individually (and not in my capacity as co-chair):

This is ground which has been well covered. Providing the practicing web
site designer with guidance is only one of the purposes of the document.
Its other functions include: (a) defining what it means for web content to
be "accessible", more abstractly than can be achieved by a set of
technology-specific requirements so that the guidelines can continue to
apply as technologies evolve; (b) offering technology designers (including
those creating, or extending, data formats) criteria with which to ensure
that their technologies are accessible; and (c) providing input to other
groups concerned with the design and development of accessible
technologies, authoring tools, etc., associated with the web. These may
include educational or policy-oriented groups--whoever finds a precise
specification of what "accessible" design amounts to, in the web arena, to
be valuable.

One of the central shortcomings which this working group has identified
with WCAG 1.0 is its failure to specify what "accessible" design means,
independently of (or more abstractly than) requirements which pertain to
particular, existing, standards and technologies. At the other end of the
continuum, it has been argued that the checkpoints in WCAG 1.0 are not
sufficiently specific and verifiable. This led to the so-called
three-level hierarchy of requirements, its having been generally agreed
that the upper two levels should comprise the guidelines.

The guidelines themselves cannot be changed without proceeding through the
W3C process. They are supposed to be (and must comprise) a stable
document, subject to change only infrequently. Consequently, it is not
practical to generate a new version whenever a new technology or standard
emerges.

However, this working group has also undertaken to publish checklists and
a techniques document which should address the need for specific and
precise, technology-specific requirements. These must be founded in, and
constitute an application of the guidelines--but unlike the latter, as
they are non-normative, they are more easily subject to change.

Of course, as Charles has often pointed out, most web content developers
should not be expected to read the guidelines, just as most content
designers don't (and are not expected to) read the HTML specification.
Rather, it is the task of authoring tools, training materials, checklists
(including those furnished by this working group) and the techniques
document to give practical guidance. When these sources are inadequate
(for example under circumstances in which one is extending a markup
language, proposing a technique of implementation and querying whether it
should count as accessible, etc.), that it becomes necessary to consult
the "official" (normative) guidelines.

Received on Tuesday, 15 August 2000 01:02:02 UTC