- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:45:24 -0700
- To: "Jean-Marie D'Amour" <jmdamour@accessibiliteweb.com>
- Cc: public-comments-WCAG20@w3.org
Dear Jean-Marie D'Amour, 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: H1-H6, Leval A or AAA? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0218.html (Issue ID: 2060) ---------------------------- Original Comment: ---------------------------- Sufficient Techniques for 1.3.1 (Level A) mentioned: H42: Using h1-h6 to identify headings. Sufficient Techniques for 2.4.9 (Level AAA) mentioned: G141: Organizing a page using headings and more specifically: In HTML, this would be done using the HTML heading elements (h1, h2, h3, h4, h5, and h6). It is confusing that a level A and a level AAA refer to the same technique. Proposed Change: Withdraw of G141 in reference with 2.4.9 in order to make clear that structuring pages with h1-h6 is a level A requirement. --------------------------------------------- Response from Working Group: --------------------------------------------- SC 1.3.1 says that if the Web page contains headings, they are marked up in a way that AT can recognize them. That is, in HTML, they are marked up with heading tags, rather than just being styles visually as headings. However, it is entirely up to the author whether or not to includes headings in the content. SC 2.4.9 says that headings are used to identify sections of the Web page. An author may need to add headings to satisfy this success criterion. Of course, if he adds headings, they must still satisfy SC 1.3.1, which means that they must be marked up properly. "G141: Organizing a page using headings" is a general technique describe how to use headings to organize content. ---------------------------------------------------------- Comment 2: SC 2.4.8: Level of priority Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0219.html (Issue ID: 2061) ---------------------------- Original Comment: ---------------------------- The purpose of each link can be identified from the link text. This is important for ease of use by screenreader users because no screenreader can easily read the context of the link as proposed by level A criterion. Proposed Change: Level AA. --------------------------------------------- Response from Working Group: --------------------------------------------- The working group recognizes that the link list mechanism provided by user agents and assistive technology will provide best results when SC 2.4.8 is satisfied. While the working group encourages authors to make link text as descriptive as possible out of context, we do not feel that this success criterion can be satisfied for all Web pages. For Example: - a page has book titles followed by PDF, HTML, DOC. - Article name (long) followed by a sentence and the link "more" - GOOGLE search where each entry has text plus the following links [translate this page] HTML and [CACHED] and [SIMILAR PAGES] - toolbar with menus with an arrow icon - the link says "open". Having full links makes the page very cluttered, harder cognitively to find things when the same long (sometimes multi-line) text is repeated with one word different, and is very long to listen to for those not adept at auditory skipping (or where unique information is back end loaded) These issues were considered carefully for a long time, the working group feels that having 2.4.4 at Level A and this issue addressed at Level AAA strikes the right balance. While user agent and assistive technology support for finding the link context is poorer than we would like, we have checked that there is at least one case of support for each of the types of link context we have listed as sufficient techniques. So a user who has tabbed to a link can ask for those pieces of context without leaving the link. We hope that if authors satisfy SC 2.4.4 and make link context programmatically determinable, user agent developers will find a way to let users access the context when needed, such as when the link list is created. The first techniques listed in 2.4.4 are: "G91: Providing link text that describes the purpose of a link H30: Providing link text that describes the purpose of a link for anchor elements (HTML) ---------------------------------------------------------- Comment 3: SC 4.1.1: Automatic testing Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0220.html (Issue ID: 2062) ---------------------------- Original Comment: ---------------------------- 4.1.1 Parsing: Content implemented using markup languages has elements with complete start and end tags, except as allowed by their specifications, and are nested according to their specifications. (Level A) I agree only if we have a tool to test it automatically. Proposed Change: Be sure that we have a tool to test it automatically. --------------------------------------------- Response from Working Group: --------------------------------------------- A specific tool to test this success criterion is definitely desirable, and vendors and toolmakers should be encouraged to produce such tools. However, the success criterion can be tested by using most any validator and then looking at the errors it identifies to see if any of these are listed. For example, any XML parser can perform these checks for XML-based content. In fact, this is already a requirement for conforming XML parsers: "Non-validating processors are REQUIRED to check only the document entity, including the entire internal DTD subset, for well-formedness." (refer to http://www.w3.org/TR/REC-xml/#proc-types). For HTML, a validator would also catch these issues, but the evaluator would need to manually check the syntax for elements that are not allowed by the specification.
Received on Sunday, 4 November 2007 04:45:34 UTC