- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:41:12 -0700
- To: "M.F. Laughton" <adio@crc.ca>
- Cc: public-comments-WCAG20@w3.org
Dear M.F. Laughton , Thank you for your comments on the 2006 Last Call Working Draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0 http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the interest that you have taken in these guidelines. We apologize for the delay in getting back to you. We received many constructive comments, and sometimes addressing one issue would cause us to revise wording covered by an earlier issue. We therefore waited until all comments had been addressed before responding to commenters. This message contains the comments you submitted and the resolutions to your comments. Each comment includes a link to the archived copy of your original comment on http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may also include links to the relevant changes in the updated WCAG 2.0 Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/. PLEASE REVIEW the decisions for the following comments and reply to us by 7 June at public-comments-WCAG20@w3.org to say whether you are satisfied with the decision taken. Note that this list is publicly archived. We also welcome your comments on the rest of the updated WCAG 2.0 Public Working Draft by 29 June 2007. We have revised the guidelines and the accompanying documents substantially. A detailed summary of issues, revisions, and rationales for changes is at http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see http://www.w3.org/WAI/ for more information about the current review. Thank you, Loretta Guarino Reid, WCAG WG Co-Chair Gregg Vanderheiden, WCAG WG Co-Chair Michael Cooper, WCAG WG Staff Contact On behalf of the WCAG Working Group ---------------------------------------------------------- Comment 1: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-941) Principle 1: Content must be perceivable. There is nothing in the current edition of WCAG to ensure Color requirements / User Choices of color/presentation/font needs are respected or requirements in the new WCAG. A low vision user doesn't want a text equivalent, they want something in a presentation they can read. Ie: 18 point font or black background and white text. Proposed Change: There should be explicit guidance relating to color/presentation/font usage, as at least a level 2 success criterion. ---------------------------- Response from Working Group: ---------------------------- Although configuring the text size, color, and font family are primarily user agent functions addressed by the User Agent Accessibility Guidelines, we have added new success criteria to address the author's responsibility for supporting text resizing: Level AA: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality. Level AAA: Visually rendered text can be resized without assistive technology up to 200 percent and down to 50 percent without loss of content or functionality and in a way that does not require the user to scroll horizontally. ---------------------------------------------------------- Comment 2: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-942) When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content. In our experience, failure to meet this criterion renders many "accessible" pages "unusable" in any practical sense. Proposed Change: Should be a level 2 criteria ---------------------------- Response from Working Group: ---------------------------- Because assistive technology cannot provide access to rerendered content if this success criterion is not satisfied, it has been moved to level A. ---------------------------------------------------------- Comment 3: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-944) The purpose of each link can be programmatically determined from the link. "Meaningful" link text is no longer a high priority: it should be. Navigating via links benefits a large number of users including those using keyboard access, voice rec, alternate input and screen reading technology. It remains in many cases the only means that many users can navigate content in an efficient and useful manner. Proposed Change: Should be a level 2 criteria ---------------------------- Response from Working Group: ---------------------------- SC 2.4.8 is at level AAA because of the potential usability problems introduced by requiring that the link text alone be sufficient. For instance, in a table of links, repeating the table header information in each cell makes the table much more difficult to use. The basic requirement that assistive technology be able to determine the purpose of the link is covered by SC 2.4.4. This success criterion has been moved to level A. ---------------------------------------------------------- Comment 4: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-945) A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. We feel that indiscriminate (and unfortunately wide-spread) use of such jargon is a greater barrier to understanding and using Web content than is implied by its relegation to level 3. Proposed Change: Should be a level 2 criteria ---------------------------- Response from Working Group: ---------------------------- SC 3.1.3 (formerly 3.1.5) is a level AAA success criterion because it cannot be applied to all web pages. Content in some fields would become extremely difficult to read if *all* specialized vocabulary had to be defined either inline or via linking, even when the terms are well known in their respective fields. Jargon is typically a barrier for people who are not in the field where the jargon is used-- e.g., the jargon of literary history may be problematic for chemical engineers but not for literary historians. Practitioners in a field are likely to provide definitions when introducing new terms or re-defining existing ones-- even when they are writing for their professional peers. We have added information to the Intent section, encouraging authors to satisfy this success criterion even for lower levels of conformance for specialized information intended for non-specialist readers. ---------------------------------------------------------- Comment 5: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-946) The document lacks any reference to dealing with "unusual user interface features or behaviours" that are likely to confuse the first-time/novice user. We feel that such should be described to the user before they are encountered. Proposed Change: Add a level 3 (at least) success criterion - perhaps to Guideline 3.1 - requiring that "Explain/describe/warn about the existence of unusual user interface features or behaviours before they are encountered. ---------------------------- Response from Working Group: ---------------------------- We've tried to address this type of scenario in the Guidelines as "predictable" behaviour and it is covered under Guideline 3.2 "Make the placement and functionality of content predictable." We've tried to further supplement it with Guideline 2.4 "Provide mechanisms to help users find content, orient themselves within it, and navigate through it". The success criteria need to be testable and it would be difficult to test for an "unusual interface." However we have added a sentence to the intent section of 2.4 that says: "Unusual user interface features or behaviors may confuse people with cognitive disabilities." ---------------------------------------------------------- Comment 6: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-947) It is felt that this is a very weak part of the guidelines. Proposed Change: A level 2 item should stress that the initial or primary "presentation of the content" is accessible, not just some version. ---------------------------- Response from Working Group: ---------------------------- Users may reach the page via a variety of paths which makes it difficult to clearly test for a default view. For instance, a search engine may link directly to the inaccessible version and for that user the inaccessible version would be the default because that is the first page that they landed on in the site when they came from the search engine. Another issue is that different users may have different content negotiation results and therefore the "default" version is could change based on user settings. We have reworked this Success Criteria and moved it to the conformance section. Alternate Versions: If the Web page does not meet all of the success criteria for a specified level, then a mechanism to obtain an alternate version that meets all of the success criteria can be derived from the nonconforming content or its URI, and that mechanism meets all success criteria for the specified level of conformance. The alternate version does not need to be matched page for page with the original (e.g. the alternative to a page may consist of multiple pages). If multiple language versions are available, then conforming versions are required for each language offered. ---------------------------------------------------------- Comment 7: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-949) Rather than attempting to explain this term, the authors provide a link to the definition in "XML Schema Part 2: Datatypes, Appendix F". The "definition" in the XML Schema is incomprehensible to the majority of us. Presumably the purpose of including a word in the glossary is to render it understandable to people who don't already understand it. Proposed Change: Please explain it in layman's terms and provide the link to XML Schema only as a supplemental reference. ---------------------------- Response from Working Group: ---------------------------- We have completely rewritten the Conformance section. The format of this description is no longer specified. The corresponding required component is now: 4. A description of the URIs that the claim is being made for, including whether subdomains are included in the claim. We have added examples to illustrate the use of boolean and regular expressions in a conformance statement. ---------------------------------------------------------- Comment 8: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-950) Some of the suggestions made in this submission - if not implemented in W2 - will possibly find inclusion in a future version of the Government of Canada's "Common Look and Feel Policy" for federal Web sites either as standards (requirements) or guidelines (optional/best practices). Unfortunately, this will lead to a "disharmonization" [sic] of standards which is in no-one's best interest. ---------------------------- Response from Working Group: ---------------------------- We have considered your suggestions (and all the others that we have received) very carefully, and have tried hard to address your issues, either in the guidelines or in advisory techniques. We agree that harmonization among accessibility standards is highly desirable. ---------------------------------------------------------- Comment 9: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-951) The baseline concept is still difficult to comprehend in real-world terms, in spite of progressive reworkings of the baseline explanation in "About Baselines and WCAG 2.0" and the less comprehensible "Conformance" section in W2. ---------------------------- Response from Working Group: ---------------------------- The conformance section of WCAG2 has been completely rewritten. The term "baseline" has been replaced by "accessibility-supported Web technologies". The issue of what it means to be an accessibility-supported Web technology is addressed in the section "Accessibility Support of Web Technologies" at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support . ---------------------------------------------------------- Comment 10: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-952) This customizable "view" of WCAG 2.0 is far and away the best thing the working group has done for the average end user. We hope this resource continues to be developed and maintained. It is likely to be the main entry point to W2 for many of our users. The opportunity to bypass inapplicable content is irresistable. Proposed Change: The same paradigm should be used for future support materials created by the GL working group and/or the Education and Outreach working group. ---------------------------- Response from Working Group: ---------------------------- Thank you. it is our plan to continue this resource and we also figured that it would be the primary entry point for developers. ---------------------------------------------------------- Comment 11: Source: http://www.w3.org/mid/F78E6BBD22A6FC4489EBE25045407908022AEFD8@msg-mb2.icent.ic.gc.ca (Issue ID: LC-953) Unfortunately, the selection form requires (or presupposes) a firmer grasp of the baseline concept than many of us have yet been able to achieve. The resulting view if a technology is used but in or not it the baseline is not as clear as we think it ought to be. Proposed Change: If feasible, it would be nice if any set of selections also generated a corresponding example of a conformance statement (metadata ready) and a verbal example of what that baseline means and how to interpret it (similar to the examples in "About Baselines and WCAG 2.0"). ---------------------------- Response from Working Group: ---------------------------- We agree but this is beyond what the Quick Reference was designed for or is capable of. We have examples in the Understanding document but do not see a way of doing this within Quick Reference. The conformance section of WCAG2 has been completely rewritten. The term "baseline" has been replaced by "accessibility-supported Web technologies". The issue of what it means to be an accessibility-supported Web technology is addressed in the section "Accessibility Support of Web Technologies" at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support .
Received on Thursday, 17 May 2007 23:41:33 UTC