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

RE: Technique Designations

From: Tim Boland <frederick.boland@nist.gov>
Date: Mon, 08 May 2006 09:25:31 -0400
Message-Id: <>
To: w3c-wai-gl@w3.org

If an offerer uses an unlisted technique (other method) as mentioned following
to "meet" the success criterion (SC) what generic guidance is available
for that offerer to explain exactly why their unlisted technique (other 
method) would meet the SC?
This guidance would not be dependent on the language of a particular technique,
but might suggest, for any such unlisted technique (other method), steps 
(approaches?) that an offerer might take
to provide demonstrable assurance that their technique would meet the SC.
If there is no such guidance, should the WCAG WG make such suggestions?
Otherwise, I think there may be the perception that unlisted techniques 
(other methods) may be somehow
"less sufficient" than the listed sufficient techniques, because these 
other methods have not yet been
evaluated by the WCAG WG for sufficiency..

Thanks and best wishes
Tim Boland NIST

At 09:44 PM 5/7/2006 -0500, you wrote:

>Loretta had stated it exactly correct.
>Please note that sufficient does NOT mean required.  A sufficient technique
>(or combination of techniques) is deemed sufficient by the working group to
>meet the success criterion.   However there may be other methods as well.
>The fact that a technique is not listed does not mean it cannot be used to
>meet the success criterion (unless of course it is listed specifically as
>one of the "common failures" of the success criterion).
>We used to have wording explaining this better in the instructions.  I see
>that it is no longer there.  Must have gotten dropped when cleaning up the
>other wording.
>Please post a comment to the public list saying
>PROBLEM:  instructions for How to Meet docs describe what 'sufficient' means
>but do not explain that other technique could also be used (except by
>Suggestion: expand description a bit to explain more clearly that
>'sufficient' doesn't mean 'only'.
>  -- ------------------------------
>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 Loretta Guarino Reid
>Sent: Sunday, May 07, 2006 6:34 PM
>To: Lisa Seeman; Chris Ridpath; WCAG
>Subject: Re: Technique Designations
>Actually, your argument is exactly the reason that the numbered techniques
>are sufficient, but not necessary. So I don't think there is a problem.
>If you use one of the techniques, your content will meet the SC.
>There is no claim that if you don't use one of the techniques, you have not
>met the SC.  As you point out, people may come up with other approaches that
>still solve the problem. And baselines that contain different sets of
>technologies will present different sets of techniques to draw from.
>On 5/7/06 5:16 PM, "Lisa Seeman" <lisa@ubaccess.com> wrote:
> >
> >
> >> 1) Sufficient - Are the numbered techniques in the "techniques for
> >> addressing" section of each SC. If followed your content will meet
> >> SC. You may have to use more than one "sufficient" tech to meet SC.
> >> If not followed then you've got to use another technique (outside the
> >> listed techniques and not one of the "common failures") to meet SC.
> >
> >
> > This looks problematic to me. If some has solved the problem, but has
> > not done it in a way we thought of this would suggest that they are
> > not good enough (even if it works, right now, with assistive
> > technology). That is blocking the evolution of accessibility and the
> > use of  new and better techniques.
> > Further we have only created techniques in "critical " technologies -
> > so if a form is made accessible using XForms, or a graphic uses SVG
> > with great grouping and descriptions then according to this they have
> > failed. Which is a bit crazy ...
> >
> >
> >
Received on Monday, 8 May 2006 13:26:13 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:45 UTC