- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:42:47 -0700
- To: "Rick Hill" <rrhill@ucdavis.edu>
- Cc: public-comments-WCAG20@w3.org
Dear Rick Hill , 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/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu (Issue ID: LC-830) 2. Being able to define entire directories of your site as off-limits to accessibility should only be allowed when the content cannot be made accessible. ---------------------------- Response from Working Group: ---------------------------- The "Scope out" language has been removed. Conformance claims must describe the set of Web pages covered by the claim. ---------------------------------------------------------- Comment 2: Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu (Issue ID: LC-831) 3. The compliance "levels" do not seem to have become simpler. Perhaps more cryptic. And I would like to see a move toward enforcible standrads rather than merely guidelines (as in what was attempted with the language of 508). ---------------------------- Response from Working Group: ---------------------------- The description of conformance levels in WCAG 2 has been rewritten to clarify the differences (see http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ): "The word "levels" does not mean that some success criteria are more important than others. Each success criterion in WCAG 2.0 is essential to some users, and the levels build upon each other. However, even content that conforms at AAA (triple-A) may not be fully accessible to every person with a disability. *In general, Level A success criteria achieve accessibility by supporting assistive technology while putting the fewest possible limits on presentation. Thus people with a wide range of disabilities using a wide range of assistive technologies, from voice input and eye-tracking devices to screen readers and screen magnifiers, are able to access content in different ways. In other words, Level A success criteria support the ability of both mainstream and specialized user agents to adapt content to formats that meet their users' needs. *The success criteria in Level AA provide additional support for assistive technology. At the same time, they also support direct access to content by the many people who use conventional user agents without assistive technology. In general, Level AA success criteria place more limits on visual presentation and other aspects of content than the success criteria in Level A. *Level AAA success criteria increase both direct access and access through assistive technology. They place tighter limits on both presentation and content." We have made testability a high priority in WCAG 2, in hopes of gaining some of the benefits of a standard versus a guideline. ---------------------------------------------------------- Comment 3: Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu (Issue ID: LC-832) 6. It would seem that WCAG 2 proposes maintaining separate accessible and inaccessible versions of the same pages. ---------------------------- Response from Working Group: ---------------------------- WCAG 2 does not promote the idea of maintaining separate accessible and inaccessible versions of the same pages, but does not prohibit maintaining separate accessible and inaccessible versions of the same pages as this accommodates the provision of versions of pages optimized for use by people with specific disabilities. Authors may use technologies that are not accessibility-supported Web technologies provided that the authors do not rely upon those technologies for conveying any information or functionality. That is, the information and functionality provided through the non-qualifying technology is also provided using accessibility-supported Web technologies. In addition, the presence of content in the non-accessibility-supported technology must not block the ability of the users to access the content via the accessible technologies. More information can be found on this in the Conformance section, http://www.w3.org/TR/2007/WD-WCAG20-20070517/#conformance . ---------------------------------------------------------- Comment 4: Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu (Issue ID: LC-833) 5. Source order must match presentation order even at the lowest level ... why? ---------------------------- Response from Working Group: ---------------------------- SC 1.3.3 does not require that the source code order match the presentation order, it requires that it be possible to programmatically determine at least one sequence of the content that makes sense. Making the source code order match the presentation order (assuming the presentation order makes sense) would be a sufficient technique, at least in HTML. However, if the technology supports it, other techniques to achieve this objective would also be sufficient, some of which are listed. Source code order is not currently listed as a sufficient technique and has specifically been de-emphasized by the Working Group. ---------------------------------------------------------- Comment 5: Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu (Issue ID: LC-829) 1. The provision to define a technology as a "baseline" is not useful unless there is either some way to make sure that the technology is inherently accessible and/or that there are provisions to provide alternate technologies to provide accessible versions of the content where the baseline technology fails. ---------------------------- Response from Working Group: ---------------------------- Even if a technology contains features that are not accessiblity supported, it can still be possible to produce conforming content as long as those features do not occur in the content. For example, let's imagine a technology that fully conforms to WCAG 2.0 with the only exception that non-text content cannot be supported with alternative text. You may not logically expect to see this technology used in a WCAG 2.0 compliance site. But the author can use this technology and claim conformance if there is no non-text content of this technology in the web pages. ---------------------------------------------------------- Comment 6: Source: http://www.w3.org/mid/C185266E-640B-404C-9432-15651031A6B4@ucdavis.edu (Issue ID: LC-834) 4. You can't use offscreen positioning to add labels (e.g., to forms) that only some people, like users of assistive technology, can perceive. Everybody has to see them. ---------------------------- Response from Working Group: ---------------------------- This technique describes a way to add hidden text to links, not to add labels to form fields. For links, this can be useful when sighted users are using the context of a link to interpret its text, but the context is not easily available to users of assistive technology. We agree that it is not appropriate to use such a technique for adding labels to forms.
Received on Thursday, 17 May 2007 23:43:10 UTC