- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 22:09:14 -0700
- To: "Roger Hudson" <rhudson@usability.com.au>
- Cc: public-comments-WCAG20@w3.org
Dear Roger Hudson, 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: SC 2.4.8 should be at higher level Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0274.html (Issue ID: 2104) ---------------------------- Original Comment: ---------------------------- The sufficient techniques for Success Criterion 2.4.4 (level A) do not appear to preclude the use of "more" or "click here" links. All that is required is the surrounding sentence of paragraph provides a context for the link. Clearly, this could result in situations where a screen reader user is presented with a list of meaningless links when they use the common navigation technique of obtaining a list of links on the page with a keyboard shortcut. Success Criterion 2.4.8 however does appear to use of descriptive and meaningful text links. This criterion however is at AAA Level, which given the importance of this issue to screen reader users is in my view inadequate Proposed Change: SC 2.4.8 should be at AA level. --------------------------------------------- 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 2: contrast ratio SC level Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0273.html (Issue ID: 2103) ---------------------------- Original Comment: ---------------------------- 1.4.3 Contrast (Minimum): Text (and images of text) have a contrast ratio of at least 5:1, except if the text is pure decoration. Larger-scale text or images of text can have a contrast ratio of 3:1. (Level AA) Comment: My comments relating to this issue last year suggested the Level should be increased to A. I was advised in general terms by the working group that the issue was discussed but no specific response to my comment was provided. I believe this is a significant accessibility issue since in my work I have observed many people (including sizable proportion of the older population)experience difficulties in differentiating between foreground and background colours used on websites. Proposed Change: 1.4.3 should be at Level A --------------------------------------------- Response from Working Group: --------------------------------------------- There are a number of ways that text can be made visible by people who have trouble with low contrast. Many OS's have a high contrast mode which makes the entire desktop high contrast, or a high contrast "highlight" feature such than any 'selected' text is highlighted in high contrast. There are also tools that will increase the contrast for people with colorblindness. As a result there are strategies for those with colorblindness or who need high contrast. 5:1 contrast is limiting on design with the availability of tools the working group felt that this provision was best at level AA. We did consider a lower bar at level A but felt that would limit design and that by not having a lower provision at Level A - those places that wanted contrast by default - and that could live with the design constraint, would specify this SC be included in their design or purchase specification. ---------------------------------------------------------- Comment 3: SC level for 3.1.3 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0275.html (Issue ID: 2105) ---------------------------- Original Comment: ---------------------------- 3.1.3 Unusual Words: A mechanism is available for identifying specific definitions of words or phrases used in an unusual or restricted way, including idioms and jargon. (Level AAA) Comment: In general WCAG 2.0 does not provide enough guidance for improving the accessibility of web content for people with cognitive, language and/or learning limitations. At the very least, providing a mechanism for enabling users to easily obtain definitions of unusual or specialist phrases should be a Level AA success criterion. Proposed Change: Change the SC for 3.1.3 to AA --------------------------------------------- Response from Working Group: --------------------------------------------- This is a new provision in WCAG 2.0 and it is not clear how difficult it will be to conform to this success criterion or whether there is any practical approach at all for some types of content - especially when technical content comes from different sources and the Webmaster or Web 'author' is not conversant in the technical matters. 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-- but would not think of defining, or even recognizing as jargon, basic and very common words in their field that they use routinely every day. With more experience it may be that techniques will be developed to handle this issue and it can be moved up in future guidelines. But at this time it is too new and the Working Group feels it should be at Level AAA. ---------------------------------------------------------- Comment 4: 3.1.4 SC should be AA Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0276.html (Issue ID: 2106) ---------------------------- Original Comment: ---------------------------- 3.1.4 Abbreviations: A mechanism for finding the expanded form or meaning of abbreviations is available. (Level AAA) Comment: In general WCAG 2.0 does not provide enough guidance for improving the accessibility of web content for people with cognitive, language and/or learning limitations. At the very least, providing a mechanism that will enable users to easily obtain an expanded form or meaning of abbreviations should be a Level AA success criterion. Proposed Change: The SC for 3.1.4 should be AA --------------------------------------------- Response from Working Group: --------------------------------------------- Many fields include acronyms among their jargon, and these would have the same difficulties discussed in our response to your comment on 3.1.3. A computer science paper with links on all the abbreviations would be very difficult to read. The working group feels that this is the appropriate level for this success criterion because it can't be applied to this type of technical content, and is therefore not appropriate for all types of sites. For these reasons, the group feels that is should remain at level AAA. It should be noted that acronyms were AAA in WCAG 1.0 as well. ---------------------------------------------------------- Comment 5: Increase SC for 3.3.4 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0277.html (Issue ID: 2107) ---------------------------- Original Comment: ---------------------------- 3.3.4 Labels or Instructions: Labels or instructions are provided when content requires user input. (Level AA) Comment: Clear labels or instructions for users when they are required to make an input are likely to benefit everyone, but can be absolutely essential for people with cognitive, language and/or learning limitations. Proposed Change: Change the SC level for 3.3.4 to A --------------------------------------------- Response from Working Group: --------------------------------------------- We have moved SC 3.3.4 (now 3.3.2) to level A. ---------------------------------------------------------- Comment 6: Success Criterion score Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0278.html (Issue ID: 2108) ---------------------------- Original Comment: ---------------------------- I feel the use of the conformance system that uses the letter A to indicate the Success Criteria level is potentially confusing. The WCAG 2.0 Success Criteria schema is different to that used in WCAG 1.0, but WCAG 1.0 also indicated Priority level compliance with the letter A. In practice, web developers and regulatory organizations used the WCAG 1.0 Priority levels as a measure for determining levels of accessibility, and they are likely to continue to do so with WCAG 2.0. And, if the letter A is to used as the indicator there is a real risk that people will believe a WCAG 2.0 AAA is the same as a WCAG 1.0 AAA and not understand the differences. As a result some important WCAG 2.00 AAA Success Criteria such as 1.4.6 are likely to be ignored. Proposed Change: The working group should develop a new system for indicating compliance levels for the Success Criteria. --------------------------------------------- Response from Working Group: --------------------------------------------- The working group has moved away from the Priority 1, 2, 3 at the specific request of people working with cognitive disabilities because it sounded like the items at level AAA were only 3rd priority things when they were in fact very important to people. Things ended up in Level AAA for a number of reasons including the fact that some could not be applied to all types of content. But not because they were 'low priority'. We considered a number of alternative terms for the levels but every combination seemed to have an issue. We have decided to retain A, AA and AAA. ---------------------------------------------------------- Comment 7: doing a little more for people with cognitive limitations Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0279.html (Issue ID: 2109) ---------------------------- Original Comment: ---------------------------- Guideline 3.1 is concerned with the need to make text readable and understandable. In general WCAG 2.0 contains very few provisions for improving the accessibility of web content for people with cognitive disabilities or learning difficulties. When this lack of specific guidance relating to people with cognitive, language and learning limitations were raised by me and other people following the release of the WCAG Last Draft in 2006, the general response of the Working Group was, \"We have added some best practices for cognitive, learning, and language disabilities as advisory techniques. We have not been able to propose many additional success criteria that meet WCAG\'s testability requirements.\" I agree it is hard to make some of the requirements for improving accessibility for people with cognitive, language and/or learning limitations machine testable. However, my reading of the definition of testability includes the provision for reliable human testable compliance. It is my view, many issues that were previously dismissed as not testable, are in fact testable by qualified human testers. Proposed change: I believe the Working Group should include the following Level AA Success Criterion for guideline 3.1. At the least, this will go some small way to addressing the short comings in relation to cognitive and learning limitations in the proposed draft of WCAG 2.0. Proposed Change: 3.1.? Comprehension: Barriers to the readability or comprehension of text, tables and forms be avoided, or a mechanism for obtaining supplementary content or an alternative version is provided. (level AA) Techniques could include: Use the clearest and simplest language appropriate for a site\'s content. Provide a mechanism for users to easily change text font size and the line-height of paragraphs. Avoid the use of complex and highly decorative backgrounds for text or provide a mechanism for users to easily remove the background. Avoid the use of highly decorative font styles for text or provide a mechanism for users to easily change the text style. Avoid the use of text line lengths in excess of 80 characters or provide a mechanism for users to easily reduce column width or line length. Avoid the use of text lines that are both left and right justified or provide a mechanism for users to easily obtain a version that is not fully justified. For technical or complex content that is to be accessible to a general audience (for example legal documents or insurance conditions), provide an additional simple-language version. (NB: I realise some of these techniques are included for other Success Criterion, however I believe that restating them here will help focus attention on the importance of considering the needs of people with cognitive, language and/or learning difficulties.) --------------------------------------------- Response from Working Group: --------------------------------------------- It is true that we allow human testability. However, the human testability must render consistent results across various experts. Because the inherent ambiguities in this field and the current level research, there are only a few techniques that we can add with confidence of agreement. However, we have added several new advisory techniques to SC 3.1.5. We have added a new success criterion at Level AAA "For the visual presentation of blocks of text, a mechanism is available to achieve the following: * foreground and background colors can be selected by the user * width is no more than 80 characters * text is not aligned on both the left and the right [LC-1253] [LC-569 (add)] * line spacing is at least space-and-a-half within paragraphs, and paragraph spacing is larger than line spacing [LC- 569] * text is resized without assistive technology up to 200 percent in a way that does not require the user to scroll horizontally to read a line of text " We believe that satisfying this success criterion will help people with some types of cognitive limitations. ---------------------------------------------------------- Comment 8: CAPTCHA Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jul/0020.html (Issue ID: 2315) ---------------------------- Original Comment: ---------------------------- I am concerned that the techniques for addressing the accessibility issues associated with the use of CAPTCHA do not adequately meet the needs of people who are both vision and hearing impaired. Proposed Change: 1. It should be clear that the use of highly distroted audio equivalents is not appropriate. 2. An additional alternative techinque should be provided that a person with impaired vision and hearing is able to use. For example, providing a contact phone number. Received on Tuesday, 3 July 2007 05:04:55 GMT --------------------------------------------- Response from Working Group: --------------------------------------------- The Working Group recognizes that CAPTCHAs create a significant barrier, and requiring only two alternate modalities will exclude some users. The WG believes, however, that this requirement strikes the best balance between benefit to users and achievability for authors. Recognizing that there are further steps possible and that authors need to be informed of the situation, we have added a note to Understanding 1.1.1 explaining the situation and providing additional recommendations, which authors are strongly encouraged to follow.
Received on Sunday, 4 November 2007 05:09:26 UTC