- From: Pasquale Popolizio <pasquale@osservatoriosullacomunicazione.com>
- Date: Fri, 16 Jun 2006 12:49:49 +0200
- To: Judy Brewer <jbrewer@w3.org>
- Cc: "EOWG (E-mail)" <w3c-wai-eo@w3.org>
Hi Judy. I really appreciate the comments and I think we have reached a good balance. I'm sorry, but for today telecom, I can use only IRC; my phone carrier is driving me crazy :-( I hope next week I can use phone. Thank you, regards ciao ~ pasquale Il giorno 16/giu/06, alle ore 06:46, Judy Brewer ha scritto: > > Hi all, > > Here is a compilation of the EOWG comments that we've talked about > at our recent EOWG meetings. Note that the comments are not yet > entered into the recommended comments form. > > We'll do a walk-through in the EOWG meeting, to confirm that the > comments are clear, and identify any remaining questions. > > Note that there are several batches of comments below. The first > batches are on the comments on the guidelines document itself; the > others are on the support material. > > Thanks for Andrew Arch for his having compiled many of these > comments during our 12 June 2006 meeting. > > Regards, > > - Judy > > > COMMENTS ON INTRO TO WCAG 2.0 (from 20060619) > http://www.w3.org/TR/WCAG20/intro.html > > 1. "Quick Table of Contents" at start of intro is confusing. > Clarify that the intro section is part of a set of pages. See > detailed comment and suggestions at: http://lists.w3.org/Archives/ > Public/w3c-wai-eo/2006AprJun/0109.html > > 2. The amount of jargon in the introduction makes it less helpful > than possible as introductory material. For instance, > ""Conformance", "success criteria", "how to meet links", "intent", > "sufficient techniques", "baseline assumptions." Copyedit for > increased use of plain English explanations. > > 3. Rephrase "'how to meet' links" for better readability. > > 4. The penultimate paragraph ("Several success criteria > require...") is difficult to understand and contains more detail > than seems necessary or appropriate for an introduction. Copyedit > to clarify and simplify. > > > COMMENTS ON CONFORMANCE TO WCAG 2.0 > http://www.w3.org/TR/WCAG20/conformance.html > > 1. [**REVISIT IN LIGHT OF FEEDBACK**] In the discussion of baseline > and conformance, it seems that there is potential for misuse of > baseline [e.g. authors might be able to just declare their own > level of technology, for instance: "requires CSS2 and JavaScript > 1.2." The actual/potential audience, not just perceived/target > audience or what developers wish they could reply on, should define > baseline. EOWG Recommends several strategies > A) to give guidance on what is a realistic baseline for most > Internet sites today, W3C should > publish a 'reasonable/realistic' baseline recommended for a general > audience; > B) update this 'recommended' baseline annually; > C) place the 'recommended' baseline outside of the WCAG 2.0 > normative document; > D) provide an explanation about why the particular baseline is > recommended > > > COMMENTS ON GUIDELINES PROPER (from 20060619) > http://www.w3.org/TR/WCAG20/guidelines.html > > 1. Difficult to parse because it is overly marked up (underline; > color; font; plus italics on glossary terms); and yellow on-hover > highlights. Recommend to at least drop italics, and possibly the on- > hover. > > 2. Success criteria 1.1.1 is difficult to parse. Success criteria > 2.2.1 is somewhat easier to parse, due to the "at least one of the > following" phrasing. Success criteria 2.5.3, same issue. Recommend > that the phrasing of parallel logical conditions should be > consistent across all success criteria, and written for high > readability; currently some of them read like riddles. > > 3. Add glossary entry for "timeout" > > > COMMENTS ON GLOSSARY (from 20060619) > http://www.w3.org/TR/WCAG20/appendixA.html > > 1. Add EOWG definition of "conformance" to WCAG 2.0 glossary, and > reference in definition of "normative" > > 2. The definition of "normative" refers to "conformance" but there > is no definition of "conformance" > > 3. [**NEEDS CLARIFICATION**] It seems restrictive to tie assistive > technology (AT) to "API-based" AT; discussion of AT only in context > of API. > > 4. [**NEEDS CLARIFICATION**] 2.0 changes significantly the > interpretation of "basic technology". > > [For more background, see http://lists.w3.org/Archives/Public/w3c- > wai-eo/2006AprJun/0114.html ] > > > COMMENTS ON CHECKLIST FOR WCAG 2.0 > http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixB.html > > 1. BUG: The caption for each table (guideline number and title) > does not display in Opera 8 > > 2. Remove the 'mouse-over' highlighting colour - adds confusion > > 3. Change 'L1' to 'Level 1' etc, and add a heading of 'Level' to > the first column > > 4. In the 'blurb' explaining what the Appendix is for, explain that > it is intended that you can save the document and add comments to > the fourth column as a report. Alternatively, provide a simpler > table and also a downloadable (RTF) document for evaluation > reporting and annotation purposes > > 5. Glossary items hard to follow because of Notes. EOWG recommends > integrating these back into the main definition, and linking back > to the main use of the term in the guidelines. > > > COMMENTS ON COMPARISON BETWEEN WCAG 1.0 and 2.0 (from 20060619) > http://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixD.html > > 1. Having an empty Quick Table of Contents is confusing; eliminate, > unless sections are added so that the quick toc is needed. > > 2. Heading of left column is unclear & needs more context. > > 3. Use of priority instead of levels seems inconsistent with the > rest of WCAG 2.0; change to "level". > > 4. Allow multiple views of comparison table, for instance: ordering > by 2.0 success criteria sequence; or by 1.0 checkpoint sequence; or > by level; or by keyword. > > 5. Clarify in intro to the comparison that this is a complex > comparison, showing both correspondences and differences. > > 6. To increase usability of the table, add a column for keywords, > and a column for type of comparison. > > 7. Improve readability by screen reader. Linearization may not work > well for this type of table, without adding extensive orientation > notes, because so complex. > > 8. Title is unclear. Recommend using: "Comparison of WCAG 1.0 > checkpoints and WCAG 2.0 success criteria" > > 9. Add a few use-cases to the intro, to highlight what this > comparison table can be used for. > > > COMMENTS ON UNDERSTANDING WCAG 2.0 > http://www.w3.org/TR/UNDERSTANDING-WCAG20/ > > 1. Helpful detail in "Understanding WCAG 2.0." EOWG sends its > compliments. > > 2. Introduction needs an opening statement along the lines of "this > is not an introductory document - it is a detailed description of > the guidelines and their success criteria" and adds a pointer to > the "Overview" > document for people requiring a simple introduction. > > 3. The title of "Understanding WCAG 2.0" continues to be a concern > for EOWG, from several directions. EOWG recommends adding an > exlanatory subheading to the document. Suggestions include: > a. Your guide to meeting the requirements of WCAG 2.0 > b. A guide to How to Meet the Web Content Accessibility > Guidelines 2.0 > c. A definitive guide to meeting WCAG 2.0 > d. The authoritative, encyclopaedic and indispensable guide to > WCAG2.0 > e. A guide to learning and implementing WCAG 2.0 > f. A guide to understanding and using WCAG 2.0 > > 4. For each guideline & success criteria, provide a couple of word > summary, rather than just a number. Sometimes referred to as > "shortname". > > > COMMENTS ON BASELINE DOCUMENT > http://www.w3.org/WAI/WCAG20/baseline/ > > 1. Re-structure the document so that there is: > - a short first section which gives you the basics of what baseline > is, without any background or examples; > - then an explanation of essential things needed to implement the > baseline concept, including examples; > - and finally a section such as an appendix that might be set up > like a Q/A, and would include other things that people may be > wondering about such as why UAAG wasn't used as the baseline, and > selected other important material from the background. > > 2. Shorten the entire "about baseline" document by as much as half, > in order to greatly increase the chance that this material will be > read and used. This shortening could be achieved by a combination > of the restructuring suggestions in several of our comments here, > plus a substantial rewriting of the text to focus less on > discussion of rationales and approaches, and more on concise > practical information that instructs the reader how to apply the > baseline concept to their use of WCAG 2.0. > > 3. Take the concepts from the first three paragraphs of the "What > is a baseline" section; simplify them (try just one or two short, > simple paragraphs); and make them an introduction to put at the > very beginning of the "About Baseline" document. If this can be > done in a way that includes simple statements about what baseline > is (for instance, in a bulleted list, or something equally terse > and clear), then also add a brief statement that baseline is not > browser or assistive technology specifications. But don't add a > statement about what it isn't unless the introduction already > includes a clear statement of what it is. > > 4. Add a prominent link from the introduction of the baseline > section to the conformance section of WCAG 2.0, and remove > redundant info about conformance from the baseline document itself. > (Note that, for now, we are not recommending the removal of > information about baseline from the conformance section of WCAG 2.0.) > > 5. Rename the "Background" section of "About baseline..." to > something such as "Why baseline is needed" or "Why baseline is > useful"; then shorten it by about 2/3 and change the perspective > from "this is what the WG did" to "this is why baseline is needed, > and what it gets you."
Received on Friday, 16 June 2006 10:50:14 UTC