Purpose of Step 1.e (was Re: [attempted summary] Techniques, Procedures, and Checklists)

Hi Richard,

Thanks for raising these questions.

The entire document is in the context of evaluation. We also use the 
term "Evaluation Commission" to differentiate from the developer. It 
seems that this could be made more clear in some sections. Specific 
suggestions for improvement would be useful (eg the first sentence in 
Step 1.e should probably read "techniques are an effective way of 
demonstrating conformance [and non-conformance] to WCAG 2.0").

The basic intent of this section is to document the step in which an 
evaluation commissioner may negotiate the use of specific techniques 
*for evaluation*; for example, a set of Techniques that is developed for 
a particular language, contest, or other contexts. The evaluator then 
uses these agreed-upon set of checklists/procedures/etc to evaluate 
conformance *with the Success Criteria*.

As this is not always the context in which evaluations take place the 
step has been declared as optional in the current draft.

I also note a previous comment from Kerstin requesting to drop this 
section all altogether. The section was reworded instead.

Regards,
   Shadi


On 14.6.2012 11:29, RichardWarren wrote:
> Dear Shadi,
>
> I am even more confused now, sorry to be so thick but now I do not
> understand the purpose of Step 1e. Is it about **evaluating**
> conformance or **demonstrating** conformance?
>
> Are you asking the evaluator to specify the techniques s/he will use to
> conduct the actual evaluation (the testing process), ?
> Or
> Are you asking someone to specify the techniques used by the developer
> to demonstrate conformance (web-design techniques).?
>
> Richard
>
>
>
> -----Original Message----- From: Shadi Abou-Zahra
> Sent: Thursday, June 14, 2012 9:38 AM
> To: Eval TF
> Subject: [attempted summary] Techniques, Procedures, and Checklists
>
> Dear Eval TF,
>
> There has been a lengthy discussion with many different points raised in
> it. This is an attempt to summarize key points to try and draw out some
> decisions; please add clarifications or points I may have missed.
>
>
> #1. Making the use of Techniques mandatory
>
> The thread was initiated in a request to make Step 1.e "Define the
> Techniques" to be used as non-optional. Here is the initial mail:
> - <http://lists.w3.org/Archives/Public/public-wai-evaltf/2012May/0008>
>
> It seems that the base assumption for this request is that developers
> will use documented Techniques and provide a comprehensive list to an
> evaluator to check. Several people have responded that this model may
> not always work, and that the methodology also needs to work when the
> evaluator has no information about how the website has been developed.
>
> *Suggested action:* decide if Step 1.e should be optional or mandatory.
>
>
> #2. Difference between Techniques and Failures
>
> A second related thread was initiated in a request to use the term "Test
> Procedure" rather than "Technique": Here is the initial mail:
> - <http://lists.w3.org/Archives/Public/public-wai-evaltf/2012Jun/0019>
>
> It seems that the motivation for this request is to differentiate
> between guidance that the developer follows to implement accessibility
> features and checks that the evaluator uses to determine barriers. It
> seems that the misunderstanding stems from the fact that WCAG 2 uses
> "Techniques" as an umbrella term for both "Sufficient Techniques" and
> "General Failures". Also "General Failures" seem less well explained.
>
> *Suggest action:* revise how we refer to and explain "WCAG Failures".
>
>
> #3. Open-ended concept of WCAG 2 Techniques
>
> Throughout the discussion there seems to be misunderstandings around the
> _concept_ of Techniques (the umbrella term) and the _instances_ of
> Techniques that are regularly published by the WCAG Working Group. It
> seems that this point also relates to the previous point about the
> clarity of explanations in WCAG 2, especially for evaluators.
>
> While we are not chartered to develop Techniques (including "General
> Failures") nor to edit the supporting documents for WCAG 2 ("Techniques
> for WCAG 2.0" and "Understanding WCAG 2.0"), we can suggest changes to
> the WCAG WG. We can also add specific explanations and references that
> are particularly relevant to evaluators in our methodology.
>
> *Suggest action:* explore potential improvements to WCAG 2 resources
> from the perspective of evaluators.
>
>
> Regards,
> Shadi
>

-- 
Shadi Abou-Zahra - http://www.w3.org/People/shadi/
Activity Lead, W3C/WAI International Program Office
Evaluation and Repair Tools Working Group (ERT WG)
Research and Development Working Group (RDWG)

Received on Thursday, 14 June 2012 09:55:28 UTC