- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:43:31 -0700
- To: "Sean Curran" <sean@srcurran.com>
- Cc: public-comments-WCAG20@w3.org
Dear Sean Curran , 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/20060622205348.5E12F47BA1@mojo.w3.org (Issue ID: LC-948) Part of Item: Examples Comment Type: editorial Comment (including rationale for proposed change): It would be helpful to show working examples of the code sample given. This would be useful in other places in the document as well. I don\'t want to create HTML files for each example. Proposed Change: Create the working examples. ---------------------------- Response from Working Group: ---------------------------- This is already true for some of our examples. We intend to continue to create working examples and convert examples to working examples as we continue to develop the Techniques document(s) and other support materials. We have added a note to the status section of the techniques draft to clarify our plans to include working examples. ---------------------------------------------------------- Comment 2: Source: http://www.w3.org/mid/20060622210606.57A0D33201@kearny.w3.org (Issue ID: LC-964) Part of Item: Intent Comment Type: substantive Comment (including rationale for proposed change): Highlighting information should also be mentioned. Many people highlight text using just a span and it is a cue to visusal users but not to computer devices. Proposed Change: Add highlighting to the list that includes emphasising, headers, strong, etc. I recommend that highlighting is a special form of em tag using css. ---------------------------- Response from Working Group: ---------------------------- SC 1.3.1 and 1.3.4 have been combined to read "Information and relationships conveyed through presentation can be programmatically determined or are available in text, and notification of changes to these is available to user agents, including assistive technologies." The How To Meet document for this combined success criterion does include highlighting via a background color in the intent section. In addition, another example about highlighting has been added to Technique G115: Using semantic elements to mark up structure. ---------------------------------------------------------- Comment 3: Source: http://www.w3.org/mid/20060622211255.5126133201@kearny.w3.org (Issue ID: LC-975) Part of Item: Intent Comment Type: substantive Comment (including rationale for proposed change): Multimedia documents are not mentioned. There are many flash documents that have a constantly moving background which is highly distracting. Multimedia should also be mentioned with luminosity and other sections. It may, however, be out of the scope of the document. Proposed Change: Include multimedia in the recomendations so people will not be in compliance if they use obnoxious moving backgrounds. ---------------------------- Response from Working Group: ---------------------------- This is covered by Success Criterion 2.2.3. The background would need to be paused unless it were essential. ---------------------------------------------------------- Comment 4: Source: http://www.w3.org/mid/20060622205348.5E12F47BA1@mojo.w3.org (Issue ID: LC-980) Part of Item: Intent Comment Type: general comment Comment (including rationale for proposed change): A few other pointers that should be included. -Don\'t use the same term/word/sentince to symbolize a link if they go different places -show links have been visited -don\'t recommend to repeat the same text over and over hard on screen readers. Proposed Change: Add the aditional pointers. ---------------------------- Response from Working Group: ---------------------------- Success criterion 3.2.4, "Components that have the same functionality within a set of Web pages are identified consistently." means that links that go to the same place should have the same description. If links that go to different places have the same description, then the description is not sufficient to determine the purpose of the link. The Intent section of How To Meet SC 2.4.4 points this out: "Links with the same purpose and destination are associated with the same description (per Success Criterion 3.2.4), but links with different purposes and destinations are associated with different descriptions." Showing links that have been visited is a User Agent responsibility, and is required by Checkpoint 10.2 of the User Agent Accessibility Guidelines (Highlight selection, content focus, enabled elements, visited links). Success Criterion 4.1.2 has been modified to require that the state of interactive controls be programmatically determined, so that user agents can satisfy this requirement. Avoiding unnecessary text repetition is an issue that the working group has struggled with. Often, text repetition is introduced by the desire to have link descriptions that make sense when read out of context. SC 2.4.4 permits links to have descriptions that depend on their context, so that contextual information won't have to be repeated. ---------------------------------------------------------- Comment 5: Source: http://www.w3.org/mid/20060622211818.2453533201@kearny.w3.org (Issue ID: LC-985) Part of Item: Intent Comment Type: general comment Comment (including rationale for proposed change): Also applies to other sections. The content must be identical. If you allow people to use mutliple versions, you must tell them that they have to keep the two identical because it is an easy way to create discrepancies and then there is an information gap. I would rather have one accessible version that exists. Proposed Change: ---------------------------- Response from Working Group: ---------------------------- While we agree that a single accessible version is desirable, the working group recognizes that there can be good reasons for providing multiple versions. The author may wish to provide different versions that use different sets of technologies, or may wish to provide versions that are tailored for people with particular disabilities. To make it clearer that the content must be equivalent, we have revised the definition of alternate version: "version that provides all of the same information and functionality in the same natural language and is as up to date as any of the non-conformant content" In addtion, we have revised the conformance section on alternate versions: 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 6: Source: http://www.w3.org/mid/20060622212402.1F3CF66364@dolph.w3.org (Issue ID: LC-986) Part of Item: Intent Comment Type: general comment Comment (including rationale for proposed change): I would add another section to 3.1 that alows users to increase or decrease the text size through the browser or the website. Or the text will work with multiple default text sizes. I think this is a bigger deal than screen readers and zooming in. Most 50 people have bad eyesight and don\'t know how to use windows zoom, but can be taught the make text bigger trick and have it as a large size by default. This breaks some websites and makes the content un-usable. Proposed Change: Add a section under 3.1 that allows users to increase the text size a reasonable amount and still have the website readable/usable/etc. ---------------------------- Response from Working Group: ---------------------------- Although resizing is primarily a user agent function, 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.
Received on Thursday, 17 May 2007 23:43:48 UTC