Re: new approach

To the group -

Per the following from the thread (from Chris), “Hmmm, but what about
everyone else? For example if A-Prompt or Bobby check a site and it passes
then I think they should be able to claim that it conforms
too.”  

I still think that there is going to be a need for developers to manually
check some aspects of accessibility as none of the evaluation tools will be
able to ascertain whether or not an alt tag, for example,  is actually
written in a useful manner.

My thoughts -

Doyle

Doyle Burnett
Education and Training Specialist
Multiple Disabilities Program
Special Education Service Agency
dburnett@sesa.org
Www.sesa.org
-- 

 

On 2/24/05 8:18 AM, "John M Slatin" <john_slatin@austin.utexas.edu> wrote:

> I like the proposed approach very much; it's elegant and clear.
>  
> Chris wrote (replying to Gregg):
> <blockquote>
>> > ...nothing but the guidelines SC are used
>> > to determine conformance.
>> >
> Yes, I agree.
> If you check your site using the SC checklist and it passes then you can claim
> conformance to the WCAG2.
> Hmmm, but what about everyone else? For example if A-Prompt or Bobby check a
> site and it passes then I think they should be able to claim that it conforms
> too. But they must put something in their claim like "it passes according to
> us". Is that OK?
> </blockquote>
> 1. A conformance claim is either valid or not; the validity of the claim has
> nothing to do with the methods used to gather the supporting evidence.
> 2. I don't think it's appropriate or necessary to require an explicit
> disclaimer (the "according to us" statement that Chris suggests). The makers
> of evaluation tools will likely want to advertise their role in verifying
> conformance, as Bobby and other tools do today for WCAG 1.0 or 508.
>  
> JohnWe've set ourselves the goal of writing success criteria that are
> testable. If *we* succeed, thenprobablyYes, I agree.
> If you check your site using the SC checklist and it passes then you can claim
> conformance to the WCAG2.
> Hmmm, but what about everyone else? For example if A-Prompt or Bobby check a
> site and it passes then I think they should be able to claim that it conforms
> too. But they must put something in their claim like "it passes according to
> us". Is that OK?
>  
>  
>  
> 
> "Good design is accessible design."
> John Slatin, Ph.D.
> Director, Accessibility Institute
> University of Texas at Austin
> FAC 248C
> 1 University Station G9600
> Austin, TX 78712
> ph 512-495-4288, f 512-495-4524
> email jslatin@mail.utexas.edu
> web http://www.utexas.edu/research/accessibility/
> <http://www.utexas.edu/research/accessibility/>
> 
>  
>> 
>> -----Original Message-----
>> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
>> Of Chris Ridpath
>> Sent: Thursday, February 24, 2005 10:54 am
>> To: Gregg Vanderheiden; w3c-wai-gl@w3.org
>> Subject: Re: new approach
>> 
>>> > ...nothing but the guidelines SC are used
>>> > to determine conformance.
>>> >
>> Yes, I agree.
>>  
>> If you check your site using the SC checklist and it passes then you can
>> claim conformance to the WCAG2.
>>  
>> Hmmm, but what about everyone else? For example if A-Prompt or Bobby check a
>> site and it passes then I think they should be able to claim that it conforms
>> too. But they must put something in their claim like "it passes according to
>> us". Is that OK?
>>  
>> Chris
>>> ----- Original Message -----
>>> From: Gregg Vanderheiden <mailto:gv@trace.wisc.edu>
>>> To: 'Chris Ridpath' <mailto:chris.ridpath@utoronto.ca>  ; w3c-wai-gl@w3.org
>>> Sent: Thursday, February 24, 2005 11:15 AM
>>> Subject: RE: new approach
>>> 
>>> Ok talk to you Thursday.
>>> 
>>>  
>>> 
>>> Key to this approach though is that nothing but the guidelines SC are used
>>> to determine conformance.  Everything else is just tools to help understand
>>> the SC and whether they have met a particular SC.
>>> 
>>>  
>>> 
>>> At least that is what it looks like.  Maybe it is how it is worded.
>>> 
>>>  
>>> 
>>> Still rolling this all around in my head.  Looking forward to your comments.
>>> 
>>>  
>>> 
>>> 
>>> Gregg
>>> 
>>>  -- ------------------------------
>>> Gregg C Vanderheiden Ph.D.
>>> Professor - Ind. Engr. & BioMed Engr.
>>> Director - Trace R & D Center
>>> University of Wisconsin-Madison
>>> 
>>>  
>>>> 
>>>>  
>>>> 
>>>> 
>>>> From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
>>>> Behalf Of Chris Ridpath
>>>> Sent: Thursday, February 24, 2005 8:37 AM
>>>> To: Gregg Vanderheiden; w3c-wai-gl@w3.org
>>>> Subject: 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 <mailto:gv@trace.wisc.edu>
>>>>> 
>>>>> To: w3c-wai-gl@w3.org <mailto: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.
>>>>>  
>>>>> 1. There would be no other checklists.
>>>>>  
>>>>> 1. 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).
>>>>> 
>>>>>  
>>>>> 1. 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.
>>>>> 
>>>>>  
>>>>> 1. 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.
>>>>>  
>>>>> 1. 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)
>>>>>  
>>>>> 1. 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).
>>>>> 
>>>>>  
>>>>> 1. 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.
>>>>>  
>>>>> 1. 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/ <http://trace.wisc.edu/> > FAX 608/262-8848
>>>>> For a list of our list discussions http://trace.wisc.edu/lists/
>>>>> 
>>>>>   <http://trace.wisc.edu:8080/mailman/listinfo/>
>>>>> 
>>>>>  
>>>>> 
>>>>>  
>