RE: difference between techniques and procedures

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

Received on Saturday, 9 June 2012 00:20:22 UTC