Re: Breaking Dependencies - @summary (FW: Call for Review: German WCAG 2.0 Candidate Authorized Translation)

L. David Baron wrote:
> On Tuesday 2009-08-04 08:21 -0700, L. David Baron wrote:
>> On Tuesday 2009-08-04 07:57 -0700, John Foliot wrote:
>>> The WAI documents are now available in multiple languages - furthering the
>>> outreach and guidance that WAI provides.  Having the HTML WD contradict
>>> WAI means that it is contradicting not only the English version, but the
>> I'd like to further understand the definition of contradict here:
>>
>>   (1) Does HTML5 contradict WCAG if it removes a feature whose use
>>   is recommended or required by WCAG?  (I'm pretty sure the answer
>>   to this one is yes.)
>>
>>   (2) Does HTML5 contradict WCAG if it improves a feature whose use
>>   is recommended or required by WCAG, and the improvement makes what
>>   is required / recommended by WCAG no longer conforming?
>>
>>   (3) Does HTML5 contradict WCAG if it improves a feature whose use
>>   is recommended or required by WCAG, but the improvement leaves
>>   what is required / recommended by WCAG as conforming?
>>
>>   (4) Does HTML5 contradict WCAG if it adds a new accessibility
>>   feature whose use is not recommended or required by WCAG?
> 
> To clarify a little why I'm asking this:
> 
> If the group believes that the answers are 1=Yes and 2,3,4=No (which
> was my initial belief), then I stand by my statement yesterday that
> John is being obstructionist (though the way I said it was over the
> top, and I apologize for that).  This is because if 2=No then an
> argument that Ian's changes should be reverted needs to explain why
> they are not an improvement, and I haven't seen John doing that.
> 
> If the group believes that the answers are 1,2=Yes and 3,4=No then
> I'd be disappointed that we can't use the definition of document
> conformance to encourage / mandate adoption of improvements in
> accessibility support.  But I'd be willing to accept it as a
> principle if we follow it consistently.
> 
> If the group believes that the answers are 1,2,3=Yes and 4=No, then
> I'd be extremely upset that the group is unable to improve the
> accessibility of existing HTML features, but I could live with it if
> there were really consensus.
> 
> I would, however, be unable to accept 1,2,3,4=Yes, since it would
> mean that HTML5 would have to remove accessibility mechanisms for
> video, canvas, etc., which I believe is unacceptable.

 From my perspective, that is a loaded question.

There is an overlap in people between the PF and HTML working groups.  I 
certainly don't view HTML as stable, but I also don't view WCAG 2.0 as 
forever.

I'd like to pose different questions, in the reverse order that you 
posed them.

4) If HTML5 adds an accessibility feature, what's the process to ensure 
that it gets an adequate review (now) and is ultimately reflected 
(later) in a subsequent edition of WCAG?

3) If HTML5 improves a feature... same question as above.

2) If an improvement turns out to be necessary, what is the process for 
coordinating a high priority errata or equivalent?

1) Let's not go there.

In addition, I believe that there is a little matter of a burden of 
proof.  There clearly are quite a few things in HTML that nobody in 
their right mind today would design that way if they were able to start 
from whole cloth.  But we are not starting from zero.  One of the things 
we start with is not just the pages that exist on the web (no matter how 
gross and ill-conceived they might be), we also start with a set of 
educational materials (again, not all of which is of uniformly high 
quality).

The way I would like to look at this is that if you or anybody else is 
proposing to make summary obsolete, you take on the whole task and not 
leave half of it undone.  What concerns me most is the attitude that 
"we" will mark it obsolete and everything else...?  *shrug*  That's 
"their" problem.

> -David

- Sam Ruby

Received on Tuesday, 4 August 2009 17:30:48 UTC