- From: <jatikalsky@mailbag.com>
- Date: 2003年9月10日 11:45:48 GMT
- To: public-comments-wcag20@w3.org
- Message-Id: <200309101145.h8ABjnRZ026129@mailbag.com>
This document has the profound effect of synthesizing the needs of those who publish webpages with the needs of those who use them. Many thanks to the working group for this work. WCAG questions: 1. In general, is this WCAG 2.0 Working Draft easy to understand? Please identify sections or phrases that are difficult to understand. Please suggest alternative wording for the Working Group to consider. + Because this document serves such as wide audience, it would be helpful to simplify the language a little unless the style is a prescribed convention for W3 documents. Could a more familiar term such as "recommended" be substituted for "normative"? I have included notes and suggested a few wording changes. 2. The conformance structure of this WCAG 2.0 Working Draft differs from WCAG 1.0 and from the previous WCAG 2.0 Working Draft. Is the concept of Core and Extended checkpoints easy to understand? Is this an effective structure? + I like the change to two levels rather than three, and the new terminology. Perhaps more people will try to satisfy both levels when there are only two. Since the new document is general and abstract to make it less technology-specific, the forthcoming supporting documents will be very helpful for specifics. 3. If your site or organization already uses WCAG 1.0, do you think it will be difficult to migrate from WCAG 1.0 to WCAG 2.0, based on the current draft? Please note that the Working Group is developing supporting documents such as technology-specific techniques documents and checklists for WCAG 2.0. + Experience with WCAG 1.0 will make it easier to figure out and use WCAG 2.0. Task-specific documents, such as "Programming webpages for accessibility" or "Writing accessible content for webpages" might helpful in addition to, or as part of, technology-specific technique documents. A potential benefit of task-oriented documents is to widen the audience and include more people in accessibility efforts. NOTES AND SUGGESTED WORDING CHANGES: How to Read this Document 2 - Technology-specific Checklists In addition to the forthcoming technology checklists, I suggest developing task-specific guides, such as "Programming webpages for accessibility," "Writing accessible content for webpages," "Editing accessible content for webpages," or "Accessibility in designing webpages" for instance. Audience Suggested wording change, "many different audiences": I suggest something like: "...many different audiences who make policy, create content, and code pages." Priorities and Techniques The mapping document is very helpful. Thank you! Best Practice for Checkpoint 2.1 (Operability) Would it be possible to include an example alternative coding method here? I'm not sure what sort of method I would try, or whether it would be acceptable. Thanks. 3.3 (Content) The recommendations for writing style apply to all types of communications media and might be too broad or tangential for accessibility guidelines. Maybe the recommendations could be placed in a separate list or supporting guidebook for editing web content. Examples of Checkpoint 3.4 (Informative) Example 2 From a usability standpoint, some designers suggest avoiding arrows before links because symbols don't give users enough information about the result of clicking the symbol. Maybe just text, such as, "[OPEN THIS LINK IN A NEW WINDOW.]" would be sufficient, right after the link, unless a page is loaded with many links of this type. More specific examples like this one would be helpful throughout the document. Example 3 So many nonfunctional Back buttons appeared with the emergence of .jsp and .asp pages that I wondered if nonfunctional Back buttons might not be easily controlled through code in some languages. Perhaps an expert in those languages has confirmed this example. Guideline 4 (Robust) Wording suggestion: "Use Web technologies that optimize content for compatibility with current and future accessibility technologies and user agents." Could an example be included? ----- Preferred address for accessibility work: Joyce Tikalsky jatikalsky@mailbag.com 608/873-6944 Also: webmaster@engr.wisc.edu 608/265-8669
Received on Wednesday, 10 September 2003 07:49:08 UTC