- From: Kerstin Probiesch <k.probiesch@googlemail.com>
- Date: Wed, 13 Jun 2012 12:34:57 +0200
- To: "'Alistair Garrison'" <alistair.j.garrison@gmail.com>, "'Eval TF'" <public-wai-evaltf@w3.org>
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:34:28 UTC