- 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