W3C home > Mailing lists > Public > public-wai-evaltf@w3.org > June 2012

Re: difference between techniques and procedures

From: Alistair Garrison <alistair.j.garrison@gmail.com>
Date: Wed, 13 Jun 2012 12:43:43 +0200
Message-Id: <CE3C41F4-93C9-4BB4-ABA3-B5D1E9A2CB4A@gmail.com>
To: Kerstin Probiesch <k.probiesch@googlemail.com>, Eval TF <public-wai-evaltf@w3.org>
Thanks Kerstin, 

For clarity - Do you follow a list of things to check, or do you just write things down as you spot them?



On 13 Jun 2012, at 12:34, Kerstin Probiesch wrote:

> Hi Alistair,
>> I asked you this before, but got no reply. Do you evaluate against a
>> checklist for WCAG 2.0 which you have developed? or is it something
>> else?
> Sorry. Seems I forgot to answer that question.
> I'm using the templates which we have in our WCAG-EM, depending on what the
> contract says (just the passes/fails, passes/fails with decription of
> findings, passes/fails with descriptions of findings and solutions for the
> problems). Sometimes I add in a summary a table how many SCs are not met in
> full for A, AA and AAA.
> Cheers
> Kerstin
>> All the best
>> Alistair
>> On 13 Jun 2012, at 09:09, Kerstin Probiesch wrote:
>>> Hi Shadi, all,
>>> I don't think that it is a problem to use the term "testing
>> procedures" because this is actually what an evaluator is doing.
>>> A lot of discussions about the relevance of the techniques has shown
>> that there are many misunderstandings and that many developers (and not
>> only developers) are thinking that it is just allowed to use techniques
>> which are in the techniques document. If we use ' techniques' even as
>> 'optional' I fear that we will bring in more confusion in this
>> discussion and I think it is likely that some take the template     but
>> use techniques or much worse an own sample of preferred techniques as
>> subsections.
>>> Best
>>> Kerstin
>>> Via Mobile
>>> Am 12.06.2012 um 23:51 schrieb Shadi Abou-Zahra <shadi@w3.org>:
>>>> Hi Mike,
>>>> Yes, it has been a lengthy thread with different points raised.
>>>> As to your comment, I don't think it is a good idea to coin new
>> terms. WCAG already differentiates between "Techniques" and "General
>> Failures".
>>>> I think we are trying to fix the wrong problem...
>>>> Best,
>>>> Shadi
>>>> On 12.6.2012 21:30, Michael S Elledge wrote:
>>>>> Hi All--
>>>>> This has been a long and exhaustive (exhausting?) thread. I think
>>>>> referring to our evaluations as "procedures" and developer methods
>> as
>>>>> "techniques" will help to reduce confusion. I also agree that it is
>>>>> important to remember that ultimately our role as evaluators is to
>>>>> determine whether a client has met the success criteria established
>> by
>>>>> the W3C in WCAG 2.0. While it may add value to point a client to a
>>>>> better technique than he/she is using, especially if their
>> technique has
>>>>> failed, it is not necessary to accomplishing our goal as evaluator.
>>>>> Mike
>>>>> On 6/8/2012 8:19 PM, Vivienne CONWAY wrote:
>>>>>> Hi Richard and all
>>>>>> I've been following the discussion, but sadly was too snowed under
>>>>>> (and that's really hard in Australia!) until this morning to
>> respond.
>>>>>> I think Richard that you capture my thoughts very concisely. In
>>>>>> reality what methods the designer uses to meet the guidelines
>> isn't
>>>>>> really the issue for us as evaluators. We need to look at what
>> methods
>>>>>> he's used to see if he's found something different that works, but
>>>>>> mostly we are checking to see that whatever techniques he uses
>> meets
>>>>>> the guidelines. As you said, if there are images, they must have
>>>>>> meaningful alternatives and conform with the guidelines for 1.1.1
>> .I
>>>>>> think we should, cite the failures - particularly if the designer
>> has
>>>>>> clearly used a documented failure technique in the design.
>>>>>> In our reporting, we obviously can talk about what different
>>>>>> techniques the designer used to meet the guidelines and what we
>> did to
>>>>>> test those features. But we do need to document carefully the
>>>>>> procedures we used for testing. In my reporting, I also describe
>> why
>>>>>> certain things the designer has done are not compliant, and
>> provide
>>>>>> suggestions for things he could do that would remedy this.
>>>>>> I think in the end if we reference our EM, that will cover a lot
>> of
>>>>>> the 'how' we tested part. I also think I'd like to see more work
>> done
>>>>>> on the Failure Techniques. I think that would help a lot of
>> designers
>>>>>> - in my mind that is who these are primarily written for. They
>> help us
>>>>>> in that we can point the designer to the Failure Technique so they
>> can
>>>>>> see the documentation of why a certain technique is not
>> acceptable.
>>>>>> Hope that all makes sense?
>>>>>> Regards
>>>>>> Vivienne L. Conway, B.IT(Hons), MACS CT, AALIA(cs)
>>>>>> PhD Candidate& Sessional Lecturer, Edith Cowan University, Perth,
>> W.A.
>>>>>> Director, Web Key IT Pty Ltd.
>>>>>> v.conway@ecu.edu.au
>>>>>> v.conway@webkeyit.com
>>>>>> Mob: 0415 383 673
>>>>>> This email is confidential and intended only for the use of the
>>>>>> individual or entity named above. If you are not the intended
>>>>>> recipient, you are notified that any dissemination, distribution
>> or
>>>>>> copying of this email is strictly prohibited. If you have received
>>>>>> this email in error, please notify me immediately by return email
>> or
>>>>>> telephone and destroy the original message.
>>>>>> ________________________________________
>>>>>> From: RichardWarren [richard.warren@userite.com]
>>>>>> Sent: Friday, 8 June 2012 9:18 PM
>>>>>> To: Shadi Abou-Zahra
>>>>>> Cc: Eval TF
>>>>>> Subject: Re: difference between techniques and procedures
>>>>>> Dear Shadi and Eval Team,
>>>>>> I am concerned that we are making things overly complex.
>>>>>> Our task is to develop a procedure for checking compliance with
>> the
>>>>>> Guidelines.
>>>>>> We are not validating the method/s used by the designer to meet
>> the
>>>>>> guidelines. - Yes it makes our job easier if the designer has used
>>>>>> specified
>>>>>> techniques etc. But the final test is "are there text alternatives
>> for
>>>>>> non-text content?", "Does it work properly when using a
>> keyboard?", "Can
>>>>>> users avoid and correct mistakes?" etc...
>>>>>> Now if I use the 'procedures' as listed by W3C to check for
>> compliance
>>>>>> with
>>>>>> each guideline I can tell the designer that I have done so and
>> that
>>>>>> his/her
>>>>>> site either complies with the guidelines, or does not. My report
>> will
>>>>>> tell
>>>>>> the designer which guidelines are complied with and which not. Any
>> third
>>>>>> party can check my results using the same procedures.
>>>>>> That is all I need to do in my role as an evaluator. (Step 4 of
>> section 3
>>>>>> Evaluation Procedure)
>>>>>> In my role as a consultant I clearly need to do a lot more by
>> identifying
>>>>>> why and where it is non-compliant and how the designer should
>> address the
>>>>>> problems etc..
>>>>>> I therefore still believe that steps 1.e and 4b should relate to
>> the
>>>>>> procedures used by the evaluator to check for compliance.
>>>>>> As for Failure Techniques, I agree that they could be better
>> written, but
>>>>>> they are more relevant to the designer and consultant (i.e.
>> analysing
>>>>>> why/how a failure happens) rather that to the evaluator.
>>>>>> Regards
>>>>>> Richard
>>>>>> -----Original Message-----
>>>>>> From: Shadi Abou-Zahra
>>>>>> Sent: Friday, June 08, 2012 1:03 PM
>>>>>> To: RichardWarren
>>>>>> Cc: Eval TF
>>>>>> Subject: Re: difference between techniques and procedures
>>>>>> I think we should continue to reference the "Techniques" rather
>> than the
>>>>>> test procedures which are a sub-part of a technique. The other
>> parts of
>>>>>> a technique can also be relevant for evaluation, for example the
>>>>>> "applicability" clauses that an evaluators needs to consider too.
>>>>>> Also, I think that one of the issues is that WCAG 2.0 and
>> supporting
>>>>>> documents do not explain "Failure Techniques" ("Common Failures")
>> [1]
>>>>>> clearly enough. We probably need to describe these a little more.
>>>>>> [1]<http://www.w3.org/TR/WCAG20-TECHS/failures.html>
>>>>>> Best,
>>>>>> Shadi
>>>>>> On 2.6.2012 12:50, RichardWarren wrote:
>>>>>>> In the light of our discussions on step 1e I think that Step 4b
>> also
>>>>>>> appears to be confusing. I think we are trying to say that we
>> will
>>>>>>> record
>>>>>>> the testing techniques as described at
>>>>>>> http://www.w3.org/TR/WCAG20-TECHS/intro.html#intro_testing_techs
>> .
>>>>>>> When W3C describes techniques in its techniques collection it
>> refers to
>>>>>>> these testing techniques as "procedures" at the end of each
>> document
>>>>>>> under
>>>>>>> the title "Tests". See an example at
>>>>>>> http://www.w3.org/TR/WCAG20-TECHS/G1.html#G1-tests
>>>>>>> We too should use the words test procedure when we refer to what
>> we do
>>>>>>> when we check for compliance. This would avoid confusion between
>> the
>>>>>>> techniques that the web-designer uses to create an accessible
>> page
>>>>>>> and the
>>>>>>> processes we, as evaluators, use to check that the page is
>> compliant
>>>>>>> (either by using a W3C technique, or some other technique).
>>>>>>> Richard
>>>>>> --
>>>>>> 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)
>>>>>> This e-mail is confidential. If you are not the intended recipient
>> you
>>>>>> must not disclose or use the information contained within. If you
>> have
>>>>>> received it in error please return it to the sender via reply e-
>> mail
>>>>>> and delete any record of it from your system. The information
>>>>>> contained within is not the opinion of Edith Cowan University in
>>>>>> general and the University accepts no liability for the accuracy
>> of
>>>>>> the information provided.
>>>>>> CRICOS IPC 00279B
>>>> --
>>>> 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 Wednesday, 13 June 2012 10:44:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:21 UTC