W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2006

RE: Common failures (was: Common failures and baseline)

From: Gregg Vanderheiden <gv@trace.wisc.edu>
Date: Wed, 24 May 2006 12:33:55 -0500
To: "'Johannes Koch'" <koch@w3development.de>, <w3c-wai-gl@w3.org>
Message-ID: <00a201c67f58$3b6963d0$ee8cfea9@NC6000BAK>

Hmmmm.

There are multiple aspects to your question.
Let me do this in steps.   

You don't pass a success criterion by passing a technique test.   The
technique tests only tell you that you pass the technique. Whether a
technique is sufficient to meet 

If you pass a technique but trigger a failure - then you fail.  No matter
who's technique.   


We document common failures to make it easier for people to avoid them.
They are failures whether we document them or not.    They are failures not
because they are documented but because you can't do them and meet the
success criterion.    

If someone creates a technique that they say meets the success criterion but
it involves something that is documented as a failure then
a) they are mistaken
or
b) the failure is written up poorly and should and would be changed.  

A properly written failure is always a failure unless or until the success
criterion is changed. 

Does that help?

Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
The Player for my DSS sound file is at http://tinyurl.com/dho6b 

-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Johannes Koch
Sent: Wednesday, May 24, 2006 2:59 AM
To: w3c-wai-gl@w3.org
Subject: Re: Common failures (was: Common failures and baseline)


Hi Gregg

Gregg Vanderheiden wrote:
> Sorry Johannes,
> 
> I didn't mean your last sentence.

I quoted _your_, not _my_ last sentence.

> A common failure causes a failure if the content you are relying on for
> conformance contains it.   If it is in an alternate version of the content
> (that is in parallel with the accessible version) then the failure (in 
> the non-accessible version) would not cause the parallel, accessible 
> version to fail unless it interfered with the accessible version.

With 'accessible version' and 'alternate version' you mean different web
units like in Situations A and B in "How to Meet Success Criterion 4.2.1"?

> RE your second question:  I am not sure what you mean by "the technique
must
> not interfere with a listed common failure."   I'm not sure what
interfering
> with a failure means?

With interfering I mean the following: You write some content. The result of
performing the test procedure for a listed common failure for SC n.n.n on
your content is "FAIL". Someone invents a technique, which he thinks to be
sufficient to meet SC n.n.n. In the reply to Tim, that I quoted, you said
this is possible (non-listed technique). The procedure for testing your
content with this technique would result in "PASS". So it is not clear
whether your content PASSes or FAILs the SC n.n.n.

IMHO this must not be possible. The test for a non-listed sufficient
technique must not result in "PASS" when the test for a listed common
failure results in "FAIL". The test for a non-listed common failure must
  not result in "FAIL" when the test for a listed sufficient technique
results in "PASS".

> Also not sure what it means for a 'test procedure to fail a success 
> criterion'.

Did I write that? But this is what I meant: For each common failure in the
"Techniques" document there is (or at least should be) a test procedure.

--
Johannes Koch
In te domine speravi; non confundar in aeternum.
                             (Te Deum, 4th cent.)
Received on Wednesday, 24 May 2006 17:34:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:46 GMT