Re: new approach

> The checklist items to determine conformance 
> with WCAG 2.0 would consist of the success criteria.
>
I like this approach. It's a nice clean model that's easy to follow.

> The tests would then be tools that could be used 
> to establish whether or not something was true, 
> not whether or not the materials conformed.
>
I think this is overly restrictive and would seriously degrade the quality of the test suite. 

> ...techniques documents would then not tell you
> what you needed to do in order conform...
>
This could seriously hamper the techniques documents.

Could we remove items 4 and 5 and modify items 7b and 7c?

Cheers,
Chris

  ----- Original Message ----- 
  From: Gregg Vanderheiden 
  To: w3c-wai-gl@w3.org 
  Sent: Wednesday, February 23, 2005 4:25 PM
  Subject: new approach 


                  For the meeting tomorrow we will be talking about the new way to look at our work.  It does not change what we are doing dramatically because it is built on all the same concepts we have been using.  However, it does change the rolls of the various documents, subtly but very importantly.  

   

                  The idea came from a discussion that Wendy and I were having one day when she suggested we could solve a number of our problems if we just made the checklist be the success criteria.  We played with the idea from there.  We came up with something like the following (see below).  I would like to take Thursday to discuss this because if we can proceed in this fashion it actually solves about four or five very large problems that we have including whether the technique specific checklists had to be normative or not, etcetera.  

   

                  Proposed Approach

   

    1.. The checklist items to determine conformance with WCAG 2.0 would consist of the success criteria.  
   

    2.. There would be no other checklists. 
   

    3.. The success criteria would have to be made more specific than they are so that it was not possible to conform to success criteria while still having inaccessible content.  
   

  (e.g., test the success criteria said that all images must have all ALT text.  You would not want an author to be able to put all of the alternative text for all of the images on their website in a single document which was located at the root of the website.  This would be alternate text and each alternate text could say which image on which page it is related to so that it would be “exclusively associated;” however, it is such a nonstandard technique that it would be of no value to anymore.  This could be fixed by perhaps adding the phrase “in a standard and supported fashion” into the success criteria).

   

    4.. Technology specific techniques documents would then not tell you what you needed to do in order conform to the success criteria; they would just help you to understand the terms in the success criteria as they related to that technology. 
   

  For example, for HTML the techniques document could simply inform the user, the reader, that the “standard and supported method” for attaching alternate text to an image was the use of the ALT attribute.  This would not have to be “normative” because it is simply a statement of fact that was all ready established in other normative documents.  

   

    5.. The tests would then be tools that could be used to establish whether or not something was true, not whether or not the materials conformed.  That is, a test would tell you whether or not had ALT text, but whether or not you had a text alternative which was explicitly associated in the standard and supported manner would be up to the person evaluating the website.  Passing the test and using the techniques document and the techniques document would of course be the safe and defensible way to establish conformance.  However, as with all situations it would leave the ability for someone to argue that they had met the success criteria in some other standard and supported fashion as well.  This allows the guidelines to have some life.  
   

    6.. Individuals who make evaluation tools could then create tools which incorporated tests for fact and would use these to construct arguments for conformity in combination with human judgments (as we know will be required to conform to WCAG 2.0) 
   

    7.. Our set of documents would then look like the following. 
   

  a)       The guidelines with their success criteria, which would be the sole defining text for conformance (which is appropriate since they are what is normative).

   

  b)       The techniques documents which would do two things.  (1) It would help to understand the terms in the guidelines as they related to specific techniques. (e.g., The standard and supported mechanism for alternative text in HTML is alt-tag.)  (2) It would provide additional advice and information on this that is useful for doing a good job.  

   

  c)       A collection of individual tests of fact.  These tests would include some but not all the things that you need to establish in order to establish conformance.  (We do not have any tests for some of the success criteria; although, it would be good if we had test procedures established for all of them).  It might also include tests that would establish whether or not other, non-required, were also true; although, these would have to be treated quite differently and perhaps cataloged separately to avoid confusion with tests for things which were required.  This is something we are still figuring out.  

   

  d)       A bare checklist which would be nothing but the success criteria.

   

  e)       Various annotated checklists which would include the success criteria plus varying levels of additional information.  (Annotated checklists with more information are more informative but longer and harder to use.  Annotated checklists with less information are more compact but require the individual to be more an expert in order to use well).

   

    8.. For example, one annotated checklist could include the success criteria plus all of the techniques that relate to the success criteria for the technologies that an author is using.  A checklist tool might be used where the author would check off the technologies that they were using.  The annotated checklist would then provide them with all of the success criteria and the information they needed to know as to what the standard and supported mechanisms for meeting the checklist were.  Again, the techniques would not define what was needed to do, but simply inform.  The fact that the ALT attribute is the proper way to add alternate text to an image is not defined by the techniques document; it is simply noted in the techniques document.  The fact that it is the standard and supported fashion is all ready a fact.  The techniques documents do not create facts; they simply reflect them.  As a result the techniques documents do not need to be normative and are informative. 
   

    9.. Other more expanded checklists could include paint-by-number methods for evaluating, etcetera. All of these methods, however, would again be informative.  The only normative information in the checklist would be the success criteria, and the only thing necessary to complete the conformance would be to satisfy all of these success criteria.  
   

                  

   

  We could talk about this more and explore it to see whether or not this looks like this will work for us.  This solves a number of big problems as we pointed out; however, including paragraph No. 1, only normative information can be used to establish conformance if techniques or checklists or tests are needed and in order to establish conformance or part of our definition of conformance then they would need to be normative.   No. 2, there can be an almost endless number of individual tests and this is good for breaking down the process of evaluating but might be a problem if it were defined as conformance.  

   

   ●  If anything besides the success criteria is normative, how do we create checklists for non-W3C technologies?  They either could never conform because there was no normative mechanism to do them or anyone would be able to create a checklist which would be as “normative” as any other.  

   

   ●   I will let us focus on this approach at the same time as we collect other issues that this might address.

   

                  Please everyone, take a look at this and try to poke holes in it.  We will then see if we can fill the holes.  If we poke holes that we cannot fill then we need to reconsider this and try to find some other to way to address our issues. 

   

                  See you Thursday, and feel free to post things to the list as well.

   

   


  Gregg

  ------------------------

  Gregg C Vanderheiden Ph.D. 
  Professor - Depts of Ind. Engr. & BioMed Engr.
  Director - Trace R & D Center 
  University of Wisconsin-Madison 
  <http://trace.wisc.edu/> FAX 608/262-8848  
  For a list of our list discussions http://trace.wisc.edu/lists/