W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > April to June 2006

Re: [Draft] Compiled EOWG comments on WCAG 2.0 Last Call Working Draft

From: Pasquale Popolizio <pasquale@osservatoriosullacomunicazione.com>
Date: Fri, 16 Jun 2006 12:49:49 +0200
Message-Id: <1C29C5CF-805A-4929-85D4-AEC17E701D6A@osservatoriosullacomunicazione.com>
Cc: "EOWG (E-mail)" <w3c-wai-eo@w3.org>
To: Judy Brewer <jbrewer@w3.org>

Hi Judy.
I really appreciate the comments and I think we have reached a good  

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,

~ 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.
> 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
> 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 ]
> 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.
> 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".
> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:29:39 UTC