- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:38:20 -0700
- To: "Judy Brewer" <jbrewer@w3.org>
- Cc: public-comments-WCAG20@w3.org
Comment 15: Source: http://www.w3.org/mid/20060623031108.30032DAF30@w3c4-bis.w3.org (Issue ID: LC-1004) Part of Item: Comment Type: editorial Comment (including rationale for proposed change): The mouse-over highlighting color adds confusion Proposed Change: EOWG suggests removing it. ---------------------------- Response from Working Group: ---------------------------- Agree. It has been removed. ---------------------------------------------------------- Comment 16: Source: http://www.w3.org/mid/20060623031328.228B2DAF30@w3c4-bis.w3.org (Issue ID: LC-1005) Part of Item: Comment Type: editorial Comment (including rationale for proposed change): The \"L1\" is unclear. Proposed Change: Change \'L1\' to \'Level 1\' etc, and add a heading of \'Level\' to the first column ---------------------------- Response from Working Group: ---------------------------- We have added a heading of "Level" to the first column as proposed and have replaced L1, L2, L3 with the appropriate level. ---------------------------------------------------------- Comment 17: Source: http://www.w3.org/mid/20060623031552.326C5DAF30@w3c4-bis.w3.org (Issue ID: LC-1006) Part of Item: Comment Type: editorial Comment (including rationale for proposed change): Some readers may not realize that you can save the checklist and add comments to the fourth column as a report. Proposed Change: In the 'blurb' explaining what the checklist 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. ---------------------------- Response from Working Group: ---------------------------- The checklist has been removed form the WCAG document itself. At this point there are no longer any checklists, just the Quick Reference. Since you and the EO working group will be involved in the creation of Checklists in the future we are forwarding your comment back to EO for use in that work. ---------------------------------------------------------- Comment 18: Source: http://www.w3.org/mid/20060623033122.A9E7E33201@kearny.w3.org (Issue ID: LC-1007) Part of Item: Comment Type: general comment Comment (including rationale for proposed change): EOWG approved the following comments prepared by Shawn Henry. Background first, on distribution of material among WCAG 2.0 and supporting documents: 1. WCAG 2.0: Purpose is a stable reference for policies, etc. Keep it as simple and succinct as possible. Clearly point to other documents for important information, such as more info on baseline (which is done in current draft). Leave out any historical info and such (take out some of what is there now). 2. Checklist: Purpose is quick list for people who already know WCAG 2.0 and just need to check off that they're remembering everything when doing an evaluation, for example. [Other common uses?] (Note that it's *not* useful as an overview for newbies.) 3. "Understanding" [or other title]: Purpose is *the* document that most people will use most of the time. Note that since all the guidelines and success criteria are in here I think few people will even look at /TR/WCAG20. [Do you agree?] * @@ 4. Techniques: Purpose is details for implementing. Assume developers are the only target audience. [correct?] 5. Overview (w3.org/WAI/intro/wcag20): Purpose is simple, friendly, directive front door to WCAG 2.0 docs. I think almost all references to WCAG 2.0 (for example, links in other WAI Resources, slides, and such) should point to this overview. 6. [About Baselines]: Eliminate this document. Put the pertinent information about baselines in "Understanding", as there's no reason to send people to yet another document for this information. The non-pertinent info that's there now could go in 7 below. 7. [something like Background, or WG Notes, or History, or QA or"¦]: Purpose is to communicate reasons why things were done, address some concerns or issues, and such. For example, move to here most of the "Background" section from About Baselines, "Why wasn't UAAG used as baseline?", and why 2.0 Levels different from 1.0 Priorities (currently in WCAG20 Conformance). 8. [Application Notes] Purpose is to help developers working on a specific thing, such as images, links, forms, data tables. (Brief description is under http://www.w3.org/WAI/intro/wcag20.php#related) Note that I think these should cover just the basics, and point back to "Understanding" & "Techniques" for the more complex issues. 9. [Plain-Language Version WCAG 2.0 "101" WCAG 2.0 "for Dummies" WCAG 2.0 Intent] Purpose is for the average person to be able to understand the basics of WCAG 2.0. I imagine taking each guideline and success criteria and providing it in an understandable way. Perhaps this is mostly pulling out the information from the "Intent" section of "Understanding". Note that this is problematic as it would have to be carefully and clearly positioned, since it would *not* cover all the issues. 10. [Quick Tips] Purpose is something short that touches on the basics to help people get started on accessibility " to fit on a business-card-sized handout. Proposed Change: The main change from what is in the current WCAG 2.0 documents and above is moving out of the main /TR/WCAG20 document Comparison with WCAG 1.0, explanatory examples, and other details. In addition to simplifying the normative doc, this puts the explanatory information where it can be updated to reflect changes over time as necessary. It also limits the need for repetition across documents (e.g., now some information in /TR/WCAG20 Conformance is repeated in About Baselines, and not at all in Understanding). I think it also would ensure that people don't miss important information. (Since it becomes clear that the /TR/WCAG20 only contains the standards, and all other info is in Understanding.) Based on above, I propose moving the following sections out of /TR/WCAG20 Conformance: I. Move into a new "Baselines" section of "Understanding": a. Under Who sets baselines?: " ... There are several reasons for this. First, what is appropriate in a baseline may differ for different environments. For example, in the case of content that will be viewed only by employees of a particular company, it may be possible to assume that user agents support more advanced technologies if the company provides the necessary user agents (including assistive technology) to all employees. For public Websites, however, a more conservative level of technology may be all that can be reasonably assumed. Baselines may also vary by jurisdiction. Finally, the level of technology that can be assumed to be supported by accessible user agents will certainly change over time. Some examples of baselines: Example 1: A government site that provides information to the public. A government agency publishes information intended for the general public. The specified baseline includes only technologies that have been widely supported by more than one accessible and affordable user agent for more than one release. The government periodically changes the baseline it requires for developers of public sites to reflect the increasing ability of affordable user agents (including assistive technology) to work with newer technologies. Example 2: A particular government provides high level accessible user agents to all citizens who need them. A government provides all citizens with user agents that support newer technologies. The government is thus able to specify a baseline that includes these newer technologies for all of its Websites for its citizens since the government can assume its citizens' user agents can handle the technologies. Example 3: A private intranet. An organization (public or private) provides its employees with the information technology tools they need to do their jobs. The baseline for intranet sites used only by employees includes newer technologies that are supported only by the user agent that the organization provides for its employees. Because the company controls the user agents that will view its internal content, the author has a very accurate knowledge of the technologies that those user agents (including assistive technologies) support. Note: In the examples above, the baseline is not specified in terms of specific user agents but rather in terms of the Web content technologies that are supported and enabled in those user agents (including assistive technologies). " b. All of Examples of conformance claims: " Examples of conformance claims Example 1: On 23 March 2005, http://www.wondercall.example.com conforms to W3C's WCAG 2.0, Conformance Level A. The baseline for this claim is XHTML 1.0. The specification that this content "relies upon" is: HTML 4.01. The specifications that this content "uses but does not rely on" are: CSS2, and gif. This content was tested using the following user agents and assistive technologies: Firefox 1.5 on Windows 2000 SP4 with Jaws 7.0, Firefox 1.5 on Windows XP SP 2 with Jaws 7.0, IE 6.0 on Windows 2000 SP4 with Jaws 4.51, IE 6.0 on Windows 2000 SP4 with Jaws 7.0, and Firefox 1.5 on Windows XP SP2 with Jaws 7.0, Safari 2.0 with OS X 10.4. Example 2: On 5 May 2006, "G7: An Introduction" http://telcor.example.com/nav/G7/intro.html conforms to W3C's WCAG 2.0. Conformance Level Double-A. The following additional success criteria have also been met: 1.1.2, 1.2.5, and 1.4.3. The baseline for this claim is UDBaseline#1-2006 at http://UDLabs.org/Baseline#1-2006.html. The specification that this content "relies upon" is: XHTML 1.0 (Strict), and Real Video. The specifications that this content "uses but does not rely on" are: JavaScript 1.2, CSS2. Example 3: On 21 June 2007, http://example.com/nav and http://example.com/docs conform to W3C's WCAG 2.0, Conformance Triple-A. The baseline is ISA-Baseline#2-2007 at http://ISA.example.gov/Baselines/BL2-2007. The specifications that this content "relies upon" are: XHTML 1.0 (Strict), CSS2, JavaScript 1.2, jpeg, png. " The technologies this content has been tested with can be found at http://example.com/docs/WCAG20/test/technologies.html. " c. All of Content that conforms to WCAG 1.0: " Content that conforms to WCAG 1.0 This Working Draft of WCAG 2.0 builds upon WCAG 1.0 and reflects feedback received since the publication of WCAG 1.0 in May 1999. The Web Content Accessibility Guidelines Working Group is working to ensure that organizations and individuals who are currently using WCAG 1.0 (which remains stable and normative at this time) will be able to smoothly transition to WCAG 2.0. For more information about the similarities and differences between WCAG 1.0 Checkpoints and WCAG 2.0 Guidelines and success criteria, please refer to the (draft) Mapping between WCAG 1.0 and the WCAG 2.0 Working Draft. Authors whose content currently conforms to WCAG 1.0 may wish to capitalize on past accessibility efforts when making the transition to WCAG 2.0. A qualified conformance statement could allow them this flexibility. For example, a conformance claim might include the following statement: "Materials with creation or modification dates before 31 December 2006 conform to WCAG 1.0. Materials with creation or modification dates after 31 December 2006 conform to WCAG 2.0." " II. Move to Document #7 [Background, or WG Notes, or History, or Q&A] above: "This method of grouping success criteria differs in important ways from the approach taken in WCAG 1.0. Each checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on accessibility. Thus, Priority 3 checkpoints appeared to be less important than Priority 1 checkpoints. The WCAG Working Group now believes that all success criteria of WCAG 2.0 are essential for some people. Thus, the system of checkpoints and priorities used in WCAG 1.0 has been replaced by success criteria under Levels 1, 2, and 3 as described above. Note that even conformance to all three levels will not make Web content accessible to all people." ---------------------------- Response from Working Group: ---------------------------- These are excellent suggestions. Below is a partial list of the actions taken to address these, and a couple of things that we have not addressed. #9 - a simple version. We have a draft but do not want to confuse people by releasing it at this time. Once the main document is out we want to work with EO to complete this. #10 Quick Tips. EO did a great job of this last time. We would like to help you to do this rather than do one ourselves. We think this would be good to do in conjunction with the SIMPLE version above. The 12 guidelines are a good starting point. We have reworked the entire document to make it shorter and easier to read and understand with different levels of expertise. This includes Easier language to understand - Wrote simpler guidelines - Removed as many technical terms (jargon) as possible replacing them with plainer language or, where possible, their definitions - Eliminated several new or unfamiliar terms. (authored unit, etc.) - Removed the term Baseline and replaced it with "web technologies that are accessibility supported" and then defined what it means to be accessibility supported. - Removed the nesting of definitions where we could (i.e. definitions that pointed to other definitions) - Tried to word things in manners that are more understandable to different levels of Web expertise - Added short names/handles on each success criterion to make them easier to find and compare etc. - Simplified the conformance Shortening the document overall - Shortened the introduction - Moved much of the discussion out of the guidelines and put it in the Understanding WCAG 2.0 document - Shortened the conformance section and moved it after the guidelines - Moved mapping from WCAG 1 to a separate support document (so it can be updated more easily) Creating a Quick Practitioner-oriented Summary / Checklist-like document - Created a Quick Reference document that has just the Guidelines, success criteria and the techniques for meeting the success criteria. ---------------------------------------------------------- Comment 19: Source: http://www.w3.org/mid/20060623034120.985C247BA1@mojo.w3.org (Issue ID: LC-1008) Part of Item: Comment Type: editorial Comment (including rationale for proposed change): The \"Quick Table of Contents\" at the start of the introduction section is confusing; it\'s unclear whether this is for the section or for the whole document. Proposed Change: Clarify that the intro section is part of a set of pages. Please see detailed comment and suggestions on re-wording at: http://lists.w3.org/Archives/Public/w3c-wai-eo/2006AprJun/0109.html ---------------------------- Response from Working Group: ---------------------------- We have removed the multi-part version of the guidelines, so the "Quick Table of Contents" is no longer present. However, we will take these recommendations into consideration as we develop other views of the WCAG 2.0 supporting materials. ---------------------------------------------------------- Comment 20: Source: http://www.w3.org/mid/20060623034355.22F2C47BA1@mojo.w3.org (Issue ID: LC-1009) Part of Item: Comment Type: editorial Comment (including rationale for proposed change): The confusion between the Intro page & the whole WCAG 2.0 continues in the \"Related Documents\" subsection Proposed Change: Clarify there that \"this document\" refers to the whole set of WCAG 2.0 pages. E.g., these are the things w/in WCAG 2.0, and then these are the things outside of WCAG 2.0 (or the WCAG 2.0 TR doc) ---------------------------- Response from Working Group: ---------------------------- We have completely revised this section of the Introduction and believe that this issue has been addressed. ---------------------------------------------------------- Comment 21: Source: http://www.w3.org/mid/20060623034521.475D847BA1@mojo.w3.org (Issue ID: LC-1010) Part of Item: Comment Type: editorial Comment (including rationale for proposed change): 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." Proposed Change: Copyedit for increased use of plain English explanations; and/or introduce the jargon later in the introduction. ---------------------------- Response from Working Group: ---------------------------- We have reworked the entire document to make it shorter and easier to read. This includes: - Shortening the introduction - Moving much of the discussion out of the guidelines and puttin it in the Understanding WCAG 2.0 document - Shortening the conformance section and moving it after the guidelines - Writing simpler guidelines - Removing as many technical terms (jargon) as possible, replacing them with simpler language or their definitions - Removing the nesting of definitions where we could (i.e. definitions that pointed to other definitions) - Moving information about mapping between WCAG 1 and WCAG 2 to a separate support document (so it can be updated more easily) - Creating a Quick Reference documents that has just the Guidelines, success criteria and the techniques for meeting the success criteria. - Trying to word things in manners that are more understandable to different levels of Web expertise - Adding short names/handles on each success criterion to make them easier to find and compare etc. - Simplifying the conformance section - Using plainer language wherever possible (e.g. – use "Web page" instead of "Web Unit") - Eliminating several new or unfamiliar terms. (authored unit, etc.) - Making the whole document much shorter. ---------------------------------------------------------- Comment 22: Source: http://www.w3.org/mid/20060623034741.C9E7647BA1@mojo.w3.org (Issue ID: LC-1012) Part of Item: Comment Type: editorial Comment (including rationale for proposed change): The fourth bulleted item (\"How to meet\" links to information on intent..\") is hard to parse Proposed Change: Re-word the fourth bulleted item for readability, for instance \"Each success criteria contains links to how to meet that criteria\" ---------------------------- Response from Working Group: ---------------------------- We have revised this item to read as follows: "How to Meet" links to information about how to meet each success criterion, including a description of the intent of the success criterion, sufficient techniques for meeting it, examples, and benefits." ---------------------------------------------------------- Comment 23: Source: http://www.w3.org/mid/20060623035437.DCE6447BA1@mojo.w3.org (Issue ID: LC-1013) Part of Item: Comment Type: editorial Comment (including rationale for proposed change): The penultimate paragraph (\"Several success criteria require...\") is difficult to understand and contains more detail than seems necessary or appropriate for an introduction. Proposed Change: Copyedit to clarify and simplify. ---------------------------- Response from Working Group: ---------------------------- We have rewritten the paragraph to be simpler and we have removed the examples of transformations that could be performed by user agents. ---------------------------------------------------------- Comment 24: Source: http://www.w3.org/mid/20060623043917.B202DBDA8@w3c4.w3.org (Issue ID: LC-1016) Part of Item: Intent Comment Type: editorial Comment (including rationale for proposed change): reposting the comment at: http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0225.html due to incorrect paste of comment. (Helpful detail in \"Understanding WCAG 2.0.\" EOWG sends its compliments) Unclear purpose of document. Proposed Change: The 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. ---------------------------- Response from Working Group: ---------------------------- Thank you. We have added the following paragraph to the Introduction. WCAG 2.0 itself is a technical standard designed primarily for Web developers and designers, authoring tool developers, evaluation tool developers, and others who need a technical standard for Web accessibility. Due to the technical and technology-independent nature of the guidelines and success criteria, and because they say what needs to be done rather than how to do it, it may sometimes be difficult to use the guidelines or success criteria for specific advice for a particular technology (e.g. HTML, XHTML, JavaScript etc)." ---------------------------------------------------------- Comment 25: Source: http://www.w3.org/mid/20060623044024.952B7BDA8@w3c4.w3.org (Issue ID: LC-1017) Part of Item: Intent Comment Type: editorial Comment (including rationale for proposed change): The title of \"Understanding WCAG 2.0\" continues to be a concern for EOWG, because of several possible misinterpretations. Proposed Change: 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 ---------------------------- Response from Working Group: ---------------------------- We have added a subheading that reads, "A guide to understanding and implementing WCAG 2.0." ---------------------------------------------------------- Comment 26: Source: http://www.w3.org/mid/20060623044126.B0D75BDA8@w3c4.w3.org (Issue ID: LC-1018) Part of Item: Intent Comment Type: editorial Comment (including rationale for proposed change): For each guideline & success criteria, provide a couple of word summary, rather than just a number. Sometimes referred to as \"shortname\". Proposed Change: ---------------------------- Response from Working Group: ---------------------------- We have included short handles in the draft to make the success criterion easier to reference. ---------------------------------------------------------- Comment 27: Source: http://www.w3.org/mid/20060623044216.4EC33BDA8@w3c4.w3.org (Issue ID: LC-1019) Part of Item: Intent Comment Type: editorial Comment (including rationale for proposed change): Proposed Change: Please add explanations of the four principles to the Understanding document. ---------------------------- Response from Working Group: ---------------------------- We have added a section to Understanding WCAG 2.0 titled, "Understanding the Four Principles of Accessibility." which includes additional explanation.
Received on Thursday, 17 May 2007 23:38:54 UTC