Re: WCAG 1.0 - Errata Update Needed

Gregg:

>It would be good to "migrate' 1.0 toward 2.0 to make later 
>transition easier.  However, I don't think we can revise 1.0 using 
>the errata mechanism.  I think that can only be used for real 
>mistakes.


Judy:

><http://www.w3.org/2003/06/Process-20030618/tr.html#rec-modify>
>
>Alistair's question seems to be requesting an update of the 
>documented errata. I believe that updating errata is usually a 
>simple process -- for those things that fall into an easily-agreed 
>upon category of "errata."

It seems that any change in content that could cause other pages to 
cease or begin conforming to a "recommendation" is the 
second-most-serious form of erratum. (New features are the most 
serious.)

>>3. Corrections that MAY affect conformance, but add no new features
>>  [...]
>>For the third class of change, W3C requires:
>>
>>    1. Review by the community to ensure the technical soundness of 
>>proposed corrections.
>>    2. Timely publication of the edited Recommendation, with 
>>corrections incorporated.
>>
>>For the third class of change, the Working Group MUST either:
>>
>>    1. Request that the Director issue a Call for Review of an 
>>Edited Recommendation, or
>>    2. Issue a Call for Review of Proposed Corrections that have not 
>>been incorporated into an edited draft (e.g., those listed on an 
>>errata page). After this review, the Director MAY announce that the 
>>proposed corrections are normative.

So any content change is not small.

>The general example that Alistair gives -- updating the errata to 
>reflect changes in changes in guidance incorporated into current 
>drafts of WCAG 2.0, but not yet reviewed by W3C Membership -- is not 
>typically what errata updates have been used for, though changes 
>that meet the criteria specified in Section 7.6.2 of the Process 
>document could be possible.

The document states: 'In this Process Document, the term "erratum" 
(plural "errata") refers to any class of mistake, from mere editorial 
to a serious error that may affect the conformance with the 
Recommendation by software or content (e.g., content validity).'

*Any class of error*. In my reading, that includes the case of "it 
didn't seem to be an error at the time, but events have since proved 
otherwise." But that-all could certainly be interpreted as adding a 
new feature, the most onerous of processes.

>The specific example that Alistair gives -- a potential change in 
>the hertz range for flashes that is considered unacceptable -- would 
>be worth examining from the perspective of those criteria. However, 
>one would need clear information on how widely accepted the new 
>range is, and possibly other information, if you wanted to be sure 
>it didn't slide over into the category of something needing 
>additional review.

According to the spec, you have to send it out for review anyway. The 
only errata you could fix without review are typing or markup errors.

>I've heard no two people agree on what "obviously" should be 
>included in an amended version. Perhaps I have missed a comprimise 
>proposal backed by WG consensus. It can be very hard to distinguish 
>what is errata, minor change, or substantial change; and therefore 
>correspondingly difficult to judge which items need which level of 
>review and approval without careful scrutiny and discussion.

According to the spec, if we change the content, it has to be 
reviewed. This is a red herring, and it is-- perhaps 
unintentionally-- a mechanism for the WAI politburo to *block* 
changes. "Well, this particular person disagreed on the mailing list 
five years ago. We don't have consensus."

>Debating which items fall into which categories can burn 
>considerable amounts of Working Group time while it is making good 
>progress towards a WCAG 2.0 Recommendation.

 From my reading, all the proposed errata are Category 3. All.

>Please note that the preparations needed to meet the review 
>requirements described under 7.6.3 "Call for Review of an Edited 
>Recommendation" and 7.6.4 "Call for Review of Proposed Corrections" 
>are not trivial, and can potentially also burn considerable amounts 
>of Working Group time.

We know that.

But the Working Group is not all that hot at managing its time as it 
is. We wouldn't be sullying a pristine organizational system here.

You'll spend weeks-- WEEKS-- shifting deck chairs on the _Titanic_ 
arguing over slight revisions to proposals that are provably false to 
begin with. You let outright untruths sit in drafts for months at a 
time. And, after mistakes are clearly pointed out and alternatives 
given (at, say, f2f meetings), you carry on as if it never happened. 
And this, implicitly, constitutes the excellent time management that 
a revised WCAG 1.0 would threaten.

WAI is in no position to chastise us in advance for proposing a 
mechanism that would *improve* WCAG 1.0 on the supposed basis that 
it's a zero-sum game: More time spent improving 1.0 means a worse 
2.0. WCAG WG is already well on the path toward a rather lousy 2.0, 
as I and others have documented at length here and elsewhere.

As Kynn points out, 1.0 is still gonna be used for many years, even 
after 2.0 comes out. 1.0 has serious flaws that are known and 
acknowledged. "Fix those first" is what people are saying here.

>Very likely almost all draft WCAG 2.0 provisions would need review 
>by the W3C Membership before being incorporated into a transition 
>version. This doesn't mean that an amended version is not a good 
>proposition; just that the likely benefits must be weighed carefully 
>against the costs of delays in progress towards WCAG 2.0.

True. But "weighed carefully" seems to be a euphemism here for "you 
have to prove it to WAI staff beyond a shadow of a doubt."



From: Kynn Bartlett <[15]kynn@idyllmtn.com>

>Those audiences will benefit greatly from a WCAG 1.0 Second Edition, 
>especially if work on WCAG 2.0 takes longer than expected

which it will. If we get something published in 2004 I'll be surprised.

I strongly support producing a WCAG 1.0 Second Edition, or any 
similar errata-corrected version of WCAG 1.0, even if it means 
slowing down 2.0.

Remember, fixing 1.0 is a task with known parameters. Whereas writing 
2.0, experience has shown, is a matter of watching the WAI politburo 
spin fantasies out of thin air, institute them in official drafts, 
and then resist months of effort to get them turned back to the real 
world. Giving a choice between fixing something, where the endpoint 
is at least easy to visualize, and letting the princes and princesses 
of the Working Group build castles in the sky and move themselves in 
even before the masonry has dried... well, I'll take the easier 
metaphor.
-- 

     Joe Clark | joeclark@joeclark.org | <http://joeclark.org/access/>
     Author, _Building Accessible Websites_ | <http://joeclark.org/book/>
     Expect criticism if you top-post

Received on Wednesday, 10 December 2003 16:11:55 UTC