W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > April 2006

comments on WCAG 2.0 requirements of 25 April 2006

From: C. M. Sperberg-McQueen <cmsmcq@acm.org>
Date: 26 Apr 2006 22:43:07 -0600
To: public-comments-wcag20@w3.org
Cc: W3C XML Coordination Group <w3c-xml-cg@w3.org>
Message-Id: <1146112987.20517.20.camel@localhost>

This email conveys some comments on "Requirements for WCAG 2.0"
http://www.w3.org/TR/2006/NOTE-wcag2-req-20060425/

The XML Coordination Group asked me to review this document, but the
XML CG has not reviewed the comments given here, and I alone am
responsible for them.

In general, the document seems clear and persuasive.  Thank you for
it.  On some points, however, I do have questions and/or suggestions.

(a) Is WCAG 2.0 intended to replace (or make obsolete, or succeed) the
XML Accessibility Guidelines document
(http://www.w3.org/TR/2002/WD-xag-20021003)?  Does the publication of
a WCAG 2.0 requirements document mean that I can remove 'Review XAG'
from my long-term guilt list?  (If it does, perhaps the time has come
to move XAG down into the list of "Working Drafts no longer in
development".  If not, then the relationship of WCAG 2.0 to XAG needs
clarification.)

(b) On requirement 1 (applicability across technologies).  I agree
that this is highly desirable, but tremble when I contemplate the
difficulties involved.  If I were you, I would either add clarifying
prose establishing an achievable standard of success for meeting this
requirement, or else classify it not as a requirement but as a goal.
(In line with the practice of some WGs, I am here taking 'requirement'
to mean something which one must do or fail, and 'goal' to mean
something one will try to do, but the omission of which does not
constitute "failure".  In those WGs, failure to achieve requirements
is a distinct cause of shame and loss of face, possibly compensated
for -- or not -- by other successes, while unachieved goals may yet
allow one to hold one's head high.)

It would be useful, perhaps, if some clearer definition were given of
what is to count as being applicable "across technologies".  A simple
reading of the requirement might assume that every rule should be
applicable to all technologies in question.  But a rule like
"Alternate text should be provided for images" can only apply to
systems in which images can be incorporated.  I hope therefore that
this simple reading of the requirement is false: it would reduce WCAG
2.0 to a discussion of features common to all target technologies and
enforce silence on any topic not universally applicable.

I suspect that with some effort I could formulate a more plausible way
to formulate the import of the first requirement.  But what is
important here is not how I might try to formulate it, based on my
understanding of the requirement, but how YOU would formulate it,
based on YOUR understanding of the requirement.

A different sort of difficulty is entailed by the fact that the
technologies you describe include specifications which operate at
different levels (if I may use that term without defining it).  Some
of the technologies mentioned define specific vocabularies which may
be used in creating Web content; others (XML, at least) are one level
of abstraction higher.  XML is a set of rules which in the first
instance govern the creation of vocabularies, and (I oversimplify
slightly) only indirectly govern the creation of content.  (More on
this below, a propos of requirement 4.)

(c) On requirement 2 (ensure that conformance requirements are clear).

The introductory paragraph says "Each requirement must be verifiable."
Readers of the WCAG 2.0 spec will be in a position to tell whether
that spec meets this requirement only if verifiability is defined more
clearly.  In particular, this reader would like clarification on
whether it means that all requirements are to be automatically
verifiable, e.g. by software, or whether verifiable requirements
include such as require intervention by human intelligence.  (I
imagine you understand quite well what I mean, but an illustration may
be offered, just in case.  The requirement that an HTML 'img' element
have a non-empty 'alt' attribute value can be checked by machine; a
requirement that it contain an accurate description, in some natural
language, of the image and its relevance to the document cannot be
checked by machine given the current state of the art in natural
language processing and artificial intelligence.)

The voices of all those who must check documents for conformance to
WCAG will surely be raised to urge you to concentrate on requirements
which can be automatically checked.  And the voices of those who rely
on conformance will, I assume, urge you with equal fervor not to limit
yourself to things that can be checked by machine, but to state the
real requirements.

The more I think about it, the more obvious it seems to me that
verifiability, in this sentence, cannot mean 'checkable by purely
automatic means' -- but I will stand by my suggestion that it would be
useful to the reader if you said so explicitly.  

(d) On requirement 4 (diverse audience)

Given the list of technologies offered in requirement 1 (and given my
assumption that WCAG 2.0 is among other things to play the role
originally envisaged for XAG), the list of audience members given here
seems incomplete.  I realize that it is introduced with the words
"including people who" and is not intended as an exclusive list.  But
still ....  Creators of content are included (in the first bullet).
Creators of vocabularies (the key users of XML, and the creators of
SVG, CSS, SMIL, etc.) are not explicitly addressed.  Nor are creators
of meta-vocabularies (e.g. those responsible for defining
meta-vocabularies like XML).

I believe the requirements document will be clearer and more useful if
you make clear either that designers of vocabularies (XML or other)
are indeed among the intended audience, or that they are not.  And
ditto for the designers of meta-language specifications like XML.  

You are between a rock and a hard place here: if you try to address
both content providers and vocabulary definers, you will have to
switch gears constantly between the level of Web content and the level
of vocabularies for Web content (or vocabularies for defining
vocabularies for Web content -- and heaven help us if someone takes it
into their minds to define a spec describing how the creators of
meta-languages ought to go about their business).  But if you don't
address the creators of vocabularies, you will not succeed in
promoting accessibility of Web content as well as I hope you will.  It
is not enough to tell creators of documents to use appropriate methods
to make their content accessible -- you must tell creators of
vocabularies that they must make it POSSIBLE for users of the
vocabularies to create accessible content.  "Use the 'alt' attribute"
on one level, "Provide for alternative delivery mechanisms, in the
spirit of the 'alt' attribute -- but preferably not as an attribute"
on a separate but perhaps even more important level.  More important
because the ratio of documents to vocabularies is n:1, with n usually
greater than 1.  But also more difficult, because the requirements
must be couched in more general and abstract terms.  Good luck.

Perhaps the solution will be to distinguish the audiences (content
providers, vocabulary providers, metalanguage providers) in the text,
in something like the same way that the Character Model distinguishes
rules for Web content from rules for specs from rules for software.  A
different solution might be to address the different levels in
different documents -- but I think that would have serious problems of
its own.

(e) On requirement 6 (compatibility)

This requirement says in part that "WCAG 2.0 should introduce as few
changes as possible to the definition of accessible Web content".

Does this mean only that content defined by WCAG 1.0 as accessible
should not be classed as inaccessible by WCAG 2.0?  

Or does it mean that content defined as inaccessible by WCAG 1.0 should
not be defined by WCAG 2.0 as accessible?

Or both?

I hope it does not mean that WCAG 2.0 must not clarify the nature of
accessibility in regions where WCAG 1.0 sheds insufficient light.  But
I take requirement 1 as a promise that it does not.

Thank you.

--C. M. Sperberg-McQueen
  World Wide Web Consortium
  MIT CSAIL
Received on Thursday, 27 April 2006 04:43:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 July 2011 06:13:19 GMT