Re: Review of WCAG 2.0 WD: structure found confusing, hiding improvements in simplicity

Jukka,

Thank you for your thoughtful comments. I have attempted to address a few 
of them.

At 07:26 AM 10/1/02, Jukka Korpela wrote:
>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?).

I have removed the link from the News section and left only the news item 
about our next telecon.

Both internal and public drafts are available to the public, but they serve 
different purposes.  The  public draft exists to solicit feedback from 
people who are not in the working group (i.e. "the public") as well as keep 
the public up-to-date with our current thinking.   Per W3C process, a 
public draft should be published every 3 months.  This is called a 
"heartbeat" requirement - every 3 months we make a bit of noise to draw 
people's attention to our most recent work.

The internal drafts should be published more often  and allow the working 
group to try out new ideas and to see changes in context.

People are able to comment on either, but we actively solicit feedback on 
the public drafts since they are more polished and stable.

>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,

I'm glad to hear you like our approach of fewer principles.  Could you 
please list which WCAG 1.0 principles are "homeless?"

>  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).

Could you give your reasons for wanting to move 4.2 under 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.

If you look at the W3C process [1],  WCAG 2.0 has to go through Last Call, 
Candidate Recommendation and Proposed Recommendation before becoming a 
Recommendation (assuming that we progress through all stages of the 
process).  We expect that the technology-specifics will be available *well 
before* we go through Last Call, so before we even enter the second major 
stage of the process (the 1st stage is a public Working Draft. We have had 
3 of these already and expect to have at least one, possibly 2 more before 
Last Call).
[1] http://www.w3.org/Consortium/Process-20010719/tr.html#Reports

The technology-specifics for WCAG 1.0 are not normative, nor will the 
technology-specifics for WCAG 2.0 be normative.  I'm concerned about your 
statement that the European parliament considers the techniques normative.

>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.

This is an interesting suggestion that we will have to consider.  I think 
you have identified an interesting issue, but we will have to consider the 
best approach to address it. Thank you for your proposal.

>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).

Another good observation.

>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".)

People who try to implement WCAG 1.0 are often unable to determine if they 
have met the requirements.  Thus, we have set a goal for ourselves to write 
testable statements.  However, as you say, some important aspects of 
accessibilty that are not easily testable are not required in and of 
themselves, but a statement about them is required.  I agree that it is not 
clear that this increases the accessibility of content.  This has been a 
primary issue that the working group has struggled with and this is our 
best approach to balance all of the factors.  Do you have a specific 
suggestion for how we can provide clear guidance to authors?

Thank you,
--wendy

-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Thursday, 3 October 2002 18:30:33 UTC