W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2001

Call for review of WCAG 2.0 draft

From: Steven McCaffrey <SMCCAFFR@MAIL.NYSED.GOV>
Date: Thu, 15 Feb 2001 11:00:20 -0500
Message-Id: <sa8bb6db.074@MAIL.NYSED.GOV>
To: <w3c-wai-gl@w3.org>
Hello WCAG 2.0 draft  editors and contributors:

     Thank you for soliciting comments on a very early draft of WCAG 2.0.
Doing this has some advantages and some disadvantages ,  as Judy indicates below.
I have commented inline below.  
Message-Id: <3.0.5.32.20010125171245.00979460@localhost>

Date: Thu, 25 Jan 2001 17:12:45 -0500

To: WAI Interest Group <
w3c-wai-ig@w3.org>

From: Judy Brewer <
jbrewer@w3.org>

Subject: Please review: Web Content Accessibility Guidelines 2.0   Working Draft



WAI Interest Group Members,



The Web Content Accessibility Guidelines Working Group (WCAG WG) of W3C's

Web Accessibility Initiative (WAI) published the first public Working Draft

of WCAG 2.0 on 25 January 2001 [1]. This Working Draft shows how more

generalized (less HTML-specific) WCAG checkpoints might read. This draft is

not based on consensus of the WCAG Working Group, nor has it gone through

W3C process. Checkpoints in this Working Draft in no way supersede the

checkpoints in WCAG 1.0. 



This is a preliminary document, not stable or referenceable yet, with much

work still to be done. If you are interested in comparing checkpoints in

WCAG 1.0 with evolving checkpoints in the WCAG 2.0 Working Draft, please

refer to the Checkpoint Mapping [2]. Feedback will be welcome throughout

the course of document development, but feedback in the early stages of

document development is especially useful.



At this stage we invite comments on two mailing lists: 

- For any comments that you want to be sure are registered with the WCAG

Working Group regarding the January 25th WCAG 2.0 Working Draft, please

send them to
w3c-wai-gl@w3.org
by Thursday, 22 February, 2001.

- For general discussion about this Working Draft, please comment on

w3c-wai-ig@w3.org. That discussion will be monitored to some extent by the

WCAG Working Group, but it does not guarantee that every issue raised there

will be registered with the Working Group for formal discussion.



The WCAG Working Group welcomes comment on any aspect of the draft, but is

particularly interested in feedback on the following issues:



	1. Are the checkpoints and guidelines in the WCAG 2.0 Working Draft easier

to understand than in WCAG 1.0?  Has terminology been used that is hard to

understand?  We realize that filling in the Glossary will help with some of

these issues. Are there terms that are not listed in the Glossary that

should be?

Steve: 
a.  easier to understand:  It depends what this phrase means.  I may "understand" something
without being able to perform a task because the term is not on a low enough level to be executed.  What background knowledge is assumed? 
b. filling in the Glossary ...:  Yes, it is not possible to give very specific comments without the definitions.
if the definitions are critical to understanding the content.
c. terms that are not listed...: Yes, accessible.  In WCAG 1.0 the definition was
"          Content is accessible when it may be used by someone with a
          disability.", which, logically, by the use of "someone" could be interpreted to mean  "at least one".  This is not the intent.
Rather it should read: Content is accessible if it may be used by a wide range of people with various characteristics, technologies, and environments" or something like this.
Some on the WAI IG list still seem to believe that if just some people can, potentially (if only they had browser x and screen reader y ...), access the page, then it is accessible.  This is of course not the case. 
 
	2. This initial public WCAG 2.0 Working Draft does not have as much

explanation for each guideline as WCAG 1.0. This is partially because the

WCAG Working Group has discussed a three-layered approach, with the first

layer being more explanatory (what are the basic ideas about Web content

accessibility, how can this document be referenced, etc.), the second layer

being the guidelines and checkpoints explaining how to make a Web site

accessible, and the third being techniques, tests, and/or examples that

would help explain how to implement this in different Web technologies.

What do people think about this approach? It might be hard to imagine since

the current Working Draft only includes the second layer, but we would

appreciate your thoughts on this.

Steve:
A three layerred approach is a good idea.  However this means the linking to the next layer is even more important.
The more abstract layer X is, the more guidance is needed to select that specific portion of the next layer that is needed to implement the guideline.  It could be the case though that the generalized guidelines are so abstract, it is not clear to the reader which link to choose.  In other words, paradoxically, he will have to read all of layer 3 in order to figure out which link in layer 2 to select.
Technically speaking, I would not describe the guidelines as "how" instructions but rather "what" instructions.  The techniques are how items.  This distinction is critical because the task of a document like this is to carefully and unambiguously provide the reader with a path from high level what items to the corresponding how items.
One person's what is another person's how.  The difference is background knowledge.
I don't know what background is assumed.  There were many discussions on WAI IG about exactly how conversant with HTML a developer needs to be.   
  
 

3. There are only 22 Checkpoints in the WCAG 2.0 Working Draft versus over

60 in WCAG 1.0. Have we generalized things too much, or does it make it

easier to grasp the concepts?

Steve: Again this depends on assumed background knowledge.  Almost by definition a generalization of a specific instance cannot be understood without knowledge of that specific instance.
Generalizations can help traverse a tree of knowledge from root to leaves or  to build a tree from leaves to root.  If "to generalize" means "to group together, to bring under one category", then I must already have knowledge of the individual instances.  However, if you are teaching something, you might start at the highestt level and then give specific examples later.  This means though that real understanding is deferred until all the examples are internalized.  If the highest levels are clear enough, it will be possible for the reader to generate her own examples.  Generalization can provide a framework in which to place a range of specific instances at a later date.
Which kind of generalization is intended?
In other words, are you trying to get the reader to create the tree or to traverse an existing one?
If you want the tree to be traversed, then it must be clear to the reader at each level, using knowledge at that level only,  which child node is appropriate.  Do I go to the HTML, XML, SVG, etc techniques document?  If I don't even know what these languages are and have never seen examples of these how will I know
which link to choose?  What level of knowledge is assumed?
Mathematics is often used as an example of a prerequisite intensive subject meaning knowledge of the subject must be "built up" on analogy with the construction of a house.  One cannot understand Calculus without having a thorough knowledge
of Algebra, Trigonometry and Analytic Geometry.  Algebra in turn cannot be understood without a thorough knowledge of Arithmetic.  However, recently, in some educational circles it is thought that teaching the "concepts" of Calculus can be taught perhaps as early as say fifth grade, that is, without the prerequisite knowledge of Algebra etc.  Well, sure, the "concept" of rates of change, slope etc. can be understood but this does not mean a fifth grader  could actually  calculate a derivative.  So, it depends on what you want your students (readers) to be able to do.  You have to break it down to very small pieces:  I want my students (readers) to be able to do: <list>"  
"I am assuming my student (reader) already can do the followoing:<list>"

     



4. Note that there are many open issues [3] that the WCAG Working Group

needs to discuss, and that this is just the first of many Working Drafts.



5. Other suggestions or comments are welcome.



This message may be circulated to other lists, but please be careful to

avoid cross-postings.



Thank you for your review,



Judy Brewer and Wendy Chisholm, on behalf of the WCAG WG



[1]
http://www.w3.org/TR/WCAG20

[
2]
http://www.w3.org/WAI/GL/WCAG20/2001/01/25-mapping.html

[
3]
http://www.w3.org/WAI/GL/wcag20-issues.html



-- 

Judy Brewer
jbrewer@w3.org    +
1.617.258.9741
http://www.w3.org/WAI

Director, Web Accessibility Initiative (WAI) International Program Office

World Wide Web Consortium (W3C)

MIT/LCS Room NE43-355, 200 Technology Square, Cambridge, MA,  02139,  USA


     I am not sure if these comments are exactly what you are looking for, but I hope they are at least thought provoking and can help further the discussion.
A good start, keep up the good work.

Steve

Steve McCaffrey
Senior Programmer/Analyst
Information Technology Services
New York State Department of Education
(518)-473-3453
smccaffr@mail.nysed.gov
Member,
New York State Workgroup on Accessibility to Information Technology 
Web Design Subcommittee 
http://web.nysed.gov/cio/access/webdesignsubcommittee.html
Received on Thursday, 15 February 2001 11:03:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:09 GMT