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