Review of WCAG 2.0 WD: structure found confusing, hiding improvem ents in simplicity

First, a very technical note: at http://www.w3.org/WAI/GL/
there is, in the News section,
"Public working draft of WCAG 2.0 published on 22 August 2002."
which links to http://www.w3.org/WAI/GL/WCAG20/ which actually
carries the date 28 August 2002. Under "Developing WCAG 2.0" there are
Current internal Working Draft - 28 August 2002 
Current public Working Draft - August 2002
with URLs
http://www.w3.org/WAI/GL/WCAG20/
http://www.w3.org/TR/WCAG20/

My comments are based on the latter, the current public draft (though I
don't quite get the difference, since both drafts are actually available to
the public, aren't they?).

In my experience from trying to explain and promote WAI guidelines, I would
say that it would be a considerable improvement to formulate the basic ideas
in a few key principles, as opposite to fourteen guidelines in WCAG 1.0. The
draft looks fundamentally OK in this respect, though there some "homeless"
principles (from WCAG 1.0) to be considered, and the relationship between
guidelines 1 and 4 in the draft is somewhat unclear. (Specifically,
checkpoint 4.2 might find a better home if placed after checkpoint 1.1).

As far as I have understood, the idea is to supplement WCAG 2.0 with more
technology-specific documents that will incorporate WCAG 1.0 (to the extent
that it should still apply). What puzzles and worries me is whether such
documents will be available when WCAG 2.0 will be issued as a recommendation
and whether they will have the same normative status as WCAG 1.0 has now.
After all, WCAG 1.0 has been stated as being a widely recognized de facto
standard. (This is what e.g. the European parliament said this year.) In
fact, sometimes I think it is taken as _too_ normative. But this status is
quite an achievement, and care should be taken not to lose it.

The structure of the guidelines in the draft is confusing. Some introductory
(and apparently non-normative) motivating notes are followed by
"checkpoints" which in turn each contain a short rule, "success criteria"
with three levels, then definitions, benefits, and examples. Without
explaining all the reasons why this might, or will, confuse people, I'd like
to propose a different approach. The "checkpoints" are actually just
guidelines that are more specific, more detailed, than the top-level
guideline; and they do not cover the entire content of the general
guideline, they just give more concrete rules. Similarly, the "success
criteria" are partly redundant, partly just guidelines at an even more
concrete level (so that they could be presented as Specific Guideline 1.1.1,
etc.). I think this should be explained, and the wording and presentation
style modified accordingly. The "levels" should not appear at all. Instead,
some informative notes could be added about the practical impact and
implementability of some guidelines when applicable. And definitions should
normally be given at (or before) the first occurrence of a term or
abbreviation, and could often be merged into running text.

The guidelines should be kept as separate from the question whether
compliance to them can be verified objectively, and in particular whether it
can be verified programmatically. Otherwise there will be strong bias
towards objective verifiability, neglecting extremely important factors that
cannot be objectively verified (such as using the simplest language
suitable, or adding illustrations when needed, or giving informative error
messages).

The proposed "success criteria" contain "level 2" criteria saying that a
checkpoint has been met if "the site has a statement asserting that the
content has been reviewed and...", followed by something that typically
refers to the beliefs of the reviewers. I find this totally pointless.
Requiring a review is somewhat debatable; it does not relate to
accessibility itself. Requiring that a specific statement is made on a Web
site about a review could be worse than meaningless. (It would not be
unrealistic if a user, upon seeing such a statement, will think that sending
any feedback will have even less chances of leading to anything, since the
authors explicitly say that they have, for example, reviewed everything and
"added as much structure as they felt was appropriate or possible".)

-- 
Jukka Korpela, senior adviser 
TIEKE Finnish Information Society Development Centre
http://www.tieke.fi/
Diffuse Business Guide to Web Accessibility and Design for All:
http://www.diffuse.org/accessibility.html

Received on Tuesday, 1 October 2002 07:26:47 UTC