W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > June 2005

RE: EOWG comments on WCAG 2.0 WD, as discussed w/ John Slatin, 2 June 2005

From: John M Slatin <john_slatin@austin.utexas.edu>
Date: Thu, 9 Jun 2005 13:14:45 -0500
Message-ID: <6EED8F7006A883459D4818686BCE3B3B01248611@MAIL01.austin.utexas.edu>
To: "Judy Brewer" <jbrewer@w3.org>, <public-comments-wcag20@w3.org>

Thanks, Judy.

Just a quick note now-- more detailed responses to come.

Earlier this week I sent a complete new draft of the Introduction to the
WCAG editors for review and comment.  I had our conversation in mind as
I wrote, along with issues raised in public-comments and logged in

The Working Group hasn't yet seen this draft-- the editors will take a
pass at it and once we're in agreement it will go to the list.

Some sections of that draft are up for discussion in the next two weeks,
especially the secton on Conformance and the note about baseline.
The results of those discussions will be integrated into the draft
Introduction, and at that time I'll review the draft Introduction
against these comments and the Bugzilla issues so I can give specific
recommendations as to issues I think we can close and those that may
remain open (I hope there won't be any of those!).


"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/


-----Original Message-----
From: Judy Brewer [mailto:jbrewer@w3.org] 
Sent: Thursday, June 09, 2005 12:46 pm
To: John M Slatin; public-comments-wcag20@w3.org
Subject: EOWG comments on WCAG 2.0 WD, as discussed w/ John Slatin, 2
June 2005

Dear John & WCAG Editors,

Following is a list of EOWG comments on WCAG 2.0 draft documents,
re-organized from EOWG's last available draft of these last fall [1] 
according to discussion between John and myself last week. My concern
many of these might have been mooted by time & intervening drafts does
seem to have held out, as they still seem largely relevant to the
draft and current editing work. Almost all relate to introductory
explanatory material, and/or format, rather than to normative items.

The comments were originally drafted based on the 30 July 2004 working 
draft of WCAG 2.0 [2], and included discussion from EOWG meetings on 27 
August, 3 September, and 10 September, however EOWG never developed a
summary of the comments at that time. My apologies for the delay in 
forwarding these.

I have organized them into the following sections, and within each
marked their status as I understood it from our conversation.
- Overall
- Introduction
- Body
- Appendices
- Techniques


1. [IMPORTANT] It is difficult to follow the transition directly from
guidelines to the success criteria. It would be helpful to have an 
explanation of the guideline available immediately following the text of

the guideline, especially for people new to Web accessibility. Or, 
alternatively, each guideline should include a brief introduction to the

guideline. Perhaps these explanations could be handled by having
views of the guidelines available.

2. Be careful about the use of jargon. Either introduce the terms when 
first used, or provide a clear link to an explanation in the glossary.
instance, terms which may need introductions but for which it appears
no explanation was available, or was not available where it would have
most helpful, include: user agent, success criteria, full range of 
disabilities, multimedia, operable, spatial pattern threshhold. With
to "spatial pattern threshhold," it would be helpful to separate out the

definition, perhaps by a box, from the individual success criteria.

3. For glossary terms, avoid using the same term as part of the
of a term, or at least don't bold-face the term when re-using it.

4. Note that the definition of "programmatically located" re-uses the
"programmatically located" but without ever explaining what 
"programmatically" means. (Also, the editorial note about
located should be moved into the glossary.) The same thing occurs within

the definition of "real-time events," which re-uses both parts of the 
compound term when defining it.

5. The blue boxes help differentiate content within the document.
the intensity of the blue is distracting for some people, and for others

makes the text unreadable because of insufficient contrast. For visual 
formatting, try other ways of differentiation, such as indentation of
content in those sections.

jumping back and forth between related sections within the document.


7. Rename the section entitled "How to read this document" to "How to
this set of documents."

ALTERNATIVES.] The term "authored unit" was unfamiliar and confusing to 
EOWG participants, even after reading the definition. EOWG discussed
possible other terms and could not come up with a better alternative at 
this time. EOWG assumes that WCAG WG is trying to get to the concept of
collection of Web content identified by a URI" or some such. Note that
a least one person, the term "unit" was interpreted as an organization,
a Web resource. We also found potential problems with the use of the
"material," "set of material," "author," and "URI" in this section. EOWG

believes that it's WCAG WG's intent that a conformance claim could be
about a single resource, such as a style sheet, image, or audio file,
if so, EOWG feels that this needs more explanation of how and why, and 
perhaps a brief example. Also EOWG noted that the definition imported
device independence seems to exclude textual content.

9. The term and concept of conformance would benefit from an
or explanation. (For instance, when first talking abt conformance, say 
something simple about it first, such as "the extent to which a web page

satisfies the requirements in these guidelines.)

10. For conformance, use the term "levels" rather than A, AA, AAA.

11. The structure of the conformance model is clearer. However, the 
description of the conformance levels needs to be stated much more
including what is meant by "Can be reasonably be applied to all Web 
resources." Some EOWG participants were not sure what this meant, and 
others were concerned and disagreed with what they thought it meant.
it refer to incorporation of the concept of feasibility into the 
conformance level, or to the effort made in implementing the
feature, or something else? EOWG participants felt that unclarity on
point would confuse the issue of how to make conformance claims.

12. [IN PROGRESS, COORDINATE W/ SHAWN] Better indicate and explain the 
navigation between the different documents (guidelines, gateway, 
techniques) including the eventual linking to, partial repetition of,
integrating of material from the introduction to WCAG 2.0. EOWG realizes

that WCAG WG is working on changes in this area.

13. [PROBABLY DONE, BUT CHECK] When explaning how to read this document,

describe what the terms "informative" and "normative" signify within the

format of the guidelines, and link them to glossary definitions.

14. [PROBABLY DONE, BUT CHECK] In the section entitled "how to read the 
document," nest the sequence of items in the top layer overview to
match the structure of the document.


15. It would be helpful to make a clearer transition from the
material into the guidelines themselves, for instance via a header which

would more clearly indicate "You are now in the actual guidelines," or

16. Change or clarify the "invisible"/"visible" distinction. However, if

the WCAG Working Group does not keep this lable as part of the format,
still would be good to retain the information somehow, such as by 
integrating it into the text.

17. Some descriptive content currently embedded in the editorial notes 
should be retained -- in some cases they are better than existing 
definitions. [Sorry, we did not document examples from EOWG discussion.]


18. The content of appendix C, relating to WCAG 1.0 to 2.0 transition, 
might be better as part of another document. However in any case it
be much more clearly and strongly linked to from the beginning of the
2.0 document. Note that having this content in a separate document from 
WCAG 2.0 would allow easier updating. It seems more important to
how WCAG 1.0 and 2.0 are different, including the mapping of the actual 
technical differences between the specifications, and much less of the 
history of how WCAG 2.0 evolved.


19. [PROBABLY DONE, BUT CHECK] The visual formatting in the online
is difficult to follow. For instance, there are many layers of
and at least four different styles of text boxes, some of which have
color contrast.

20. [PROBABLY DONE, BUT CHECK] The formatting in the printed version is 
difficult to follow because of an extremely small font size; check for 
style sheet bugs.

21. Explain terms when first using them. Be careful about the sequence
when a term is first used and when it is defined.

22. [DISCUSSED BUT NOT YET SETTLED] Consider whether the techniques 
documents should have their own glossaries -- or better yet -- consider 
making the glossary a sortable database module within the set of
& techniques documents, rather than explicitly part of the guidelines 
document, and then enabling glossary subsets that would be relevant to
of the documents in the set. This might be accomplished by integrating
WCAG glossary into the evolving W3C-wide glossary.

23. [MAY NOT BE A BETTER ALTERNATIVE] Use words rather than code (e.g.
L2 SC1") for link text in the techniques documents.

24. [WCAG DISCUSS WITH SHAWN] Make the formats of the gateway &
documents more consistent and simple.


[1] Last draft of EOWG comments

[2] July 30 working draft http://www.w3.org/TR/2004/WD-WCAG20-20040730/

Judy Brewer    +1.617.258.9741    http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI), World Wide Web Consortium
(W3C) MIT/CSAIL Building 32-G530 32 Vassar Street Cambridge, MA,  02139,
Received on Thursday, 9 June 2005 18:14:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:14:37 UTC