- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:56:06 -0700
- To: "Kiyochika Nakamura?" <nakamura-kiyochika@mitsue.co.jp>
- Cc: public-comments-WCAG20@w3.org
Dear Kiyochika Nakamura, Thank you for your comments on the 17 May 2007 Public Working Draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0 http://www.w3.org/TR/2007/WD-WCAG20-20070517/). The WCAG Working Group has reviewed all comments received on the May draft, and will be publishing an updated Public Working Draft shortly. Before we do that, we would like to know whether we have understood your comments correctly, and also whether you are satisfied with our resolutions. Please review our resolutions for the following comments, and reply to us by 19 November 2007 at public-comments-wcag20@w3.org to say whether you are satisfied. Note that this list is publicly archived. Note also that we are not asking for new issues, nor for an updated review of the entire document at this time. Please see below for the text of comments that you submitted and our 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 WCAG 2.0 Editor's Draft of May-October 2007 at http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20071102/ Thank you for your time reviewing and sending comments. Though we cannot always do exactly what each commenter requests, all of the comments are valuable to the development of WCAG 2.0. Regards, 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: validity Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0064.html (Issue ID: 1989) ---------------------------- Original Comment: ---------------------------- Source: http://www.w3.org/mid/449A8F1D.5080403@mitsue.co.jp (Issue ID: LC-1239) Comment: The term, "parsed unambiguously," or "parsed into only one data structure" is not good enough to comply with the principle 4. The principle states that "content should be robust enough to work with current and future user agents." Then, if web units or authored components are well-formed but include information not based on chosen technologies, can we guarantee that this information is conveyed? Therefore, I believe if forward compatibility is important, "conforming to specifications" would be better than "parsed unambiguously." Proposed Change: Using the phrase "conforming to specifications" instead of the phrase "parsed unambiguously." ---------------------------- Response from Working Group: ---------------------------- The working group looked at this topic carefully over an extended period of time and concluded that requiring strict adherence to all aspects of specifications does not necessarily result in an increase in accessibility. For example, it is possible to create invalid pages that present no accessibility barriers. It is also possible in certain situations to enhance accessibility through the use of markup that is not part of the specification. The working group must work within its charter and only include things that directly affected accessibility. Some aspects of "use technologies according to specification" and validity do relate to accessibility. However, others do not. So requiring validity would take us beyond our charter. We do recommend it though and it is our #1 technique listed for conforming to SC 4.1.1. -------------------------------- Response from Kiyochika Nakamura: -------------------------------- Overall, we are satisfied with the WG's decisions, but for the Comment 6, though we feel that the new success criterion is much better than the old one, there still is a question. It looks like the new success criterion still allows "user agent-dependent" elements, such as BLINK or MARQUEE for (X)HTML. This affects accessibility for user agents which cannot interpret those elements. We understand that other examples such as tabindex attribute for some elements, which is invalid, could be good for accessibility, but if a document makes a declaration of the document type, it should follow its rules. Also, we believe that WCAG, as a W3C spec, should respect other W3C specs. This comment does NOT mean that we think it is unacceptable, however, we hope the WG takes into consideration our opinion in anyway possible. --------------------------------------------- Response from Working Group: --------------------------------------------- The wording of this success criterion does permit the use of elements that are not defined by the applicable specification. This is permitted because the elements, in and of themselves, do not interfere the the possibility of parsing the document into a usable representation. In addition, such elements sometimes enhance accessibility even though they do not exist in the specification. This situation is addressed by the concept explained in the Conformance section on Accessibility Support of Web Technologies . If a given feature is supported by user agents, regardless of whether it is defined in the technology specification, it meets the requirements for accessibility support. By contrast, if a feature is not supported by user agents even though it is defined in the specification, it does not meet the definition of accessibility supported and cannot be relied on to achieve WCAG 2.0 conformance. The Working Group also respects the perspective that, as a W3C Specification, WCAG 2.0 should actively support other W3C Specifications. However, due to the ongoing evolution of technologies and user agent support, it is often the case that there is not a canonical specification against which requirements may be made. The current wording for the success criterion attempts to address that balance in the most effective way possible. Two examples of items that people try to get at through validity that we address because of their specific disability impact are BLINK and MARQUEE, which are specifically listed as failures because of their impact on users with disabilities. (See F47: Failure of SC 2.2.2 due to using the blink element and F16: Failure of SC 2.2.3 due to including scrolling content where movement is not essential to the activity without also including a mechanism to pause and restart the content.)
Received on Sunday, 4 November 2007 04:56:25 UTC