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

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

From: Judy Brewer <jbrewer@w3.org>
Date: Thu, 09 Jun 2005 13:45:35 -0400
Message-Id: <5.1.0.14.2.20050602130856.030bb2d8@localhost>
To: "John M Slatin" <john_slatin@austin.utexas.edu>, public-comments-wcag20@w3.org

Dear John & WCAG Editors,

Following is a list of EOWG comments on WCAG 2.0 draft documents, somewhat 
re-organized from EOWG's last available draft of these last fall [1] 
according to discussion between John and myself last week. My concern that 
many of these might have been mooted by time & intervening drafts does not 
seem to have held out, as they still seem largely relevant to the current 
draft and current editing work. Almost all relate to introductory material, 
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 final 
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 section 
marked their status as I understood it from our conversation.
- Overall
- Introduction
- Body
- Appendices
- Techniques

OVERALL

1. [IMPORTANT] It is difficult to follow the transition directly from the 
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 different 
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. For 
instance, terms which may need introductions but for which it appears that 
no explanation was available, or was not available where it would have been 
most helpful, include: user agent, success criteria, full range of 
disabilities, multimedia, operable, spatial pattern threshhold. With regard 
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 definition 
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 term 
"programmatically located" but without ever explaining what 
"programmatically" means. (Also, the editorial note about programatically 
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. However, 
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 the 
content in those sections.

6. [RECONSIDER, GIVEN CHANGES IN NAVIGATION] Add more links to facilitate 
jumping back and forth between related sections within the document.

INTRODUCTION

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

8. [EOWG DID NOT GUESS RIGHT, AND WCAG WG HAS ALREADY TRIED MANY 
ALTERNATIVES.] The term "authored unit" was unfamiliar and confusing to 
EOWG participants, even after reading the definition. EOWG discussed some 
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 "a 
collection of Web content identified by a URI" or some such. Note that for 
a least one person, the term "unit" was interpreted as an organization, not 
a Web resource. We also found potential problems with the use of the terms 
"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 made 
about a single resource, such as a style sheet, image, or audio file, but 
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 from 
device independence seems to exclude textual content.

9. The term and concept of conformance would benefit from an introduction 
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 clearly, 
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. Does 
it refer to incorporation of the concept of feasibility into the 
conformance level, or to the effort made in implementing the accessibility 
feature, or something else? EOWG participants felt that unclarity on this 
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, and 
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 better 
match the structure of the document.

BODY

15. It would be helpful to make a clearer transition from the introductory 
material into the guidelines themselves, for instance via a header which 
would more clearly indicate "You are now in the actual guidelines," or some 
such.

16. Change or clarify the "invisible"/"visible" distinction. However, if 
the WCAG Working Group does not keep this lable as part of the format, it 
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.]

APPENDICES

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 should 
be much more clearly and strongly linked to from the beginning of the WCAG 
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 highlight 
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.

TECHNIQUES

19. [PROBABLY DONE, BUT CHECK] The visual formatting in the online version 
is difficult to follow. For instance, there are many layers of indenting, 
and at least four different styles of text boxes, some of which have poor 
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 of 
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 guidelines 
& techniques documents, rather than explicitly part of the guidelines 
document, and then enabling glossary subsets that would be relevant to each 
of the documents in the set. This might be accomplished by integrating the 
WCAG glossary into the evolving W3C-wide glossary.

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

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

Footnotes:

[1] Last draft of EOWG comments
http://lists.w3.org/Archives/Public/w3c-wai-eo/2004JulSep/0198

[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,  USA
Received on Thursday, 9 June 2005 17:46:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 July 2011 06:13:18 GMT