EOWG Comments on WCAG 2.0 Dec 2007 - Draft

EOWG,

Below are draft EOWG Comments on the WCAG Last Call Working Draft documents published 11 December 2007 <http://www.w3.org/TR/WCAG20/> These are due on this Friday, 1 February.

A. OPEN ACTION ITEM for LIAM and LISA:
Document: Several
Comment Type: General
current wording: "accessibility supported"
suggested revision: "accessibility-supporting"
ACTION ITEM: Craft clear, strong justification of this, taking into consideration WCAG's draft thoughts addressed that are included in http://lists.w3.org/Archives/Public/w3c-wai-eo/2008JanMar/0070.html
See also Wayne's input at: http://lists.w3.org/Archives/Public/w3c-wai-eo/2008JanMar/0071.html
And Liam's previous comment: rationale: poor grammar - subject/object has been confused, this makes it difficult to parse. The present form requires that 'accessibility' supports the technology. This is not the case - the technology must support accessibility. Hence accessibility-supporting. Hyphenation gives a further improvement to ease of parsing, making clear that 'accessibility-supporting' is an adjective of 'technology'. Hyphenation is presently used in some instances of accessibility-supported, and should in any case be consistent throughout.

Document: Understanding & Techniques
Great. Nice typographic layout :)
Any chance the page layout of the content pages could be used for the TOC as well?
ACTION, LIAM: Please be more specific.

B. FOR EOWG DISCUSSION:

Document: WCAG 2.0 Guidelines
Comment type: Editorial
Location: Introduction, WCAG 2.0 Layers of Guidance
current wording: "At the top are four principles"; "Under the principles are guidelines"
suggested revision: "There are four principles"; "Within each principle are guidelines"
rationale: makes the semantic relationship clearer, removes the visual metaphor of on top and under.
EOWG DISCUSSION: Does "top" and "under" help to clarify the relationship, and therefore should be left. Or, does it complicate the relationship?

C. Reply to this list of you think these need discussion, otherwise will submit them as is:

Document: WCAG 2.0 Guidelines
Comment type: Editorial
Location: Abstract
current wording: "Guidance about satisfying the Success Criteria in specific technologies as well as general information about interpreting the Success Criteria are provided in separate documents."
suggested revision: "Guidance about satisfying the Success Criteria in specific technologies, as well as general information about interpreting the Success Criteria, are provided in separate documents."
rationale: makes this sentence easier to parse.

Document: WCAG 2.0 Guidelines
Comment type: Editorial
Location: Introduction, WCAG 2.0 Layers of Guidance
current wording: "Metadata may assist users in finding content most suitable for their needs."
suggested revision: "_Metadata_ may assist users in finding content most suitable for their needs." with "metadata" linked to a definition or location where it is explained.
rationale: metadata is jargon and needs linking to a definition.

Document: WCAG 2.0 Guidelines
Comment type: Editorial?Technical
location: Guideline 1.1
current wording: "Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language"
suggested revision: "Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content"
rationale: "so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language" is the rationale behind the Guidelines and therefore should not be included in the guideline text for several reasons, including:
- the rationale isn't included in the text of the other guidelines or SC
- the extra wording makes it more complex to parse the guideline text
- it could encourage the guideline to be interpreted to be restricted to the cases listed
- it is easier to skim the documents without the additional rationale in the guideline text
- (and, many people know this already)

Document: WCAG 2.0 Guidelines
Comment type: Editorial
location: Conformance
Current wording: "This section lists requirements for conformance to WCAG 2.0 as well as information about how to make conformance claims, which are optional. It also introduces..."
Suggested revision: "This section lists requirements for conformance to WCAG 2.0. It also gives information about how to make conformance claims, which are optional, and introduces..."
rationale: it could be legally argued that it the current form leaves it ambiguous as to whether the phrase 'which is optional' applies to the second phrase of the sentence, or the first and second. We don't think that this is a comprehension problem, yet a potential legal one.

Document: WCAG 2.0 Guidelines
Comment type: Technical
location: Glossary
Definition - changes of context
Should these not be examples rather than a complete definition? - I can't think of another context, but doesn't mean that one won't be developed eventually.
LIAM: Please confirm that you meant "changes of context" - in http://www.w3.org/2002/09/wbs/35532/WCAG20-11Dec12008/results you have "Definition - Context"

Document: WCAG 2.0 Guidelines
Comment type: Editorial
location: Glossary
Definition - Programmatically determiend
Spelling error: determined
Capitalisation inconsistency: should be lower case

Document: WCAG 2.0 Guidelines
Comment type: Editorial
location: Appendix B: Acknowledgments
Other previously active WCAG WG participants and other contributors to WCAG 2.0
Suggest including *everyone* who has made a contribution to WCAG2.0 - 1500 comments? Gives strong authority to the document. Could be pulled off into another page.

Document: Quick Reference
location: title
current wording: WCAG 2.0 Quick Reference: A customizable list of WCAG 2.0 requirements (Success Criteria) and techniques
suggested revision: How to Meet WCAG 2.0: A customizable list of WCAG 2.0 requirements (Success Criteria) and techniques -or- Guide to Meeting WCAG 2.0: A customizable list of WCAG 2.0 requirements (Success Criteria) and techniques 
rationale: There could be some very negative reactions to this being called "Quick" since it is 30-40+ printed pages. (Remember the negative comments on the size/length of the WCAG 2.0 documents previously.) "How to meet X.X" is the link text in the guidelines, so it makes sense to have the document name more closely match that.

Document: Quick Reference
location: customization options
suggested revision: allow users to filter out HTML techniques
rationale: lets users filter out a bunch of info that is not necessary in certain use cases, e.g., wanting to look up only multimedia or CSS related issues. (note that several EOWG participants tried to do this and were overwhelmed with the number of techniques still listed.)

Document: Quick Reference
location: Introduction, first part
current wording:
"See the Overview of WCAG 2.0 Documents for an introduction to Web Content Accessibility Guidelines (WCAG) 2.0 and supporting documents. 
This Quick Reference is based on the 11 December 2007 WCAG 2.0 draft. It lists all of the requirements (called "success criteria") in WCAG 2.0, along with techniques to meet the requirements. You can customize this Quick Reference to list only the information that you are interested in.
To use the Quick Reference:
In the Customizing section, check the technologies and conformance levels you are interested in. 
The [Understanding Guideline x] and [Understanding Success Criterion x.x.x] links take you to the relevant section of the Understanding WCAG 2.0 document, which explains the intent of the guidelines and success criteria; provides examples and techniques; and describes how they help people with different disabilities.
"
suggested revision:
<p>
This WCAG 2.0 Quick Reference lists all of the requirements (called "success criteria") from the latest _Web Content Accessibility Guidelines (WCAG) 2.0 Working Draft_. It also lists techniques to meet the requirements, which link to more details. The "Understanding" links go to descriptions, examples, and resources.
<p>
You can customize the list by selecting the technologies that apply to your web project, and the _levels_ and techniques that you want included in the list.
<p>
See the _Overview of WCAG 2.0 Documents_ for an introduction to WCAG 2.0 and supporting documents, including more information about this Quick Reference.

rationale: first say what the document is. simplify. cut down on wording. (having such a long introduction is counter to a primary goal with the "Quick Reference" which is to help make WCAG 2.0 approachable.)

Document: Quick Reference
location: Introduction, first part
current wording:
"Note that all techniques are informative. The "sufficient techniques" listed below are considered sufficient by the WCAG Working Group to meet the success criteria. However, it is not necessary to use these particular techniques. If techniques are used other than those listed by the Working Group, then some other method for establishing the technique's ability to meet the success criteria would be needed.
In addition to the 'sufficient techniques', there are also advisory techniques that go beyond WCAG 2.0's requirements. Sufficient and advisory techniques work together to provide guidance on how to make content more accessible. Authors are encouraged to view and apply all layers that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users. 
Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability particularly in the cognitive language and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, as well as to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community. 
Anyone can submit new techniques to the Working Group at any time. Please see Sufficient and Advisory Techniques for more information about sufficient techniques and advisory techniques.
"

suggestion:
"Note that all techniques are informative - you don’t have to follow them. <strong>Please see the _“Sufficient and Advisory Techniques” section of Introduction to Understanding WCAG 2.0_ for important information about the techniques.</strong>"
-OR:
"Note that all techniques are informative - you don’t have to follow them. The "sufficient techniques" listed below are considered sufficient to meet the success criteria; however, it is not necessary to use these particular techniques. Anyone can submit new techniques at any time.

In addition to the 'sufficient techniques', there are also advisory techniques that go beyond WCAG 2.0's requirements. Authors are encouraged to apply all techniques that they are able to, including the advisory techniques, in order to best address the needs of the widest possible range of users.

Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive language and learning areas. Authors are encouraged to seek relevant advice about current best practice to ensure that Web content is accessible, as far as possible, to this community.

Please see Sufficient and Advisory Techniques for more information about the techniques.
"

rationale: simplify. cut down on wording. (having such a long introduction is counter to a primary goal with the "Quick Reference" which is to help make WCAg 2.0 approachable.)

D. SUGGEST NOT SUBMITTING:
The following comments are already fixed or addressed in the latest Editor's Draft or resolution to comments, and therefore I do not think we need to submit them.

Document: WCAG 2.0 Guidelines
Comment type: Editorial
location: Glossary
Definition - Idiom
Example Numbering has missed 1.
Corrected in current Editors Draft <http://www.w3.org/WAI/GL/WCAG20/#idiomsdef>

Document: WCAG 2.0 Guidelines
Location: Introduction, Important Terms in WCAG 2.0, Accessibility Supported 
Current wording: "Only "accessibility supported" technologies can be used to conform to WCAG 2.0 Success Criteria Technologies that are not accessibility supported (do not work with AT etc.) can be used, but cannot be used to conform to any Success Criterion.
Corrected wording (added missing period) in current Editors Draft: Only "accessibility supported" technologies can be used to conform to WCAG 2.0 Success Criteria. Technologies that are not accessibility supported (do not work with AT etc.) can be used, but cannot be used to conform to any Success Criterion.

Document: WCAG 2.0 Guidelines
Location: Glossary
current wording: "switch back and forth between two visual states in a way that is meant to draw attention"
suggested revision: "switch back and forth between two visual states"
rationale: you can't test authorial intention.
>From WCAG Issue tracking: DONE Refined definition of "blink": switch back and forth between two visual states in a way that that does not qualify as [flash] (e.g. it is too slow or the change in relative luminance is too small to qualify as flashing)

Document: WCAG 2.0 Quick Reference
Comment: Should be able to show/hide TOC and cusomization box
Note: EOWG did not come to an agreement on this point. Some felt it was not worth the extra interface elements. Also note that the Customization box is hidden when the page is printed.

Received on Thursday, 31 January 2008 03:49:33 UTC