- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Thu, 24 Feb 2005 10:15:12 -0600
- To: "'Chris Ridpath'" <chris.ridpath@utoronto.ca>, <w3c-wai-gl@w3.org>
- Message-ID: <auto-000219279007@spamarrest.com>
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: <mailto:gv@trace.wisc.edu> Gregg Vanderheiden
To: <mailto:w3c-wai-gl@w3.org> 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/> 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/>
Received on Thursday, 24 February 2005 16:15:26 UTC