- From: Roger Hudson <rhudson@usability.com.au>
- Date: Mon, 19 Nov 2007 09:35:58 +1100
- To: <public-comments-wcag20@w3.org>
- Cc: "'Loretta Guarino Reid'" <lorettaguarino@google.com>
Hi Loretta and Working Group Thanks for the responses to my comments concerning the last Public Working Draft of WCAG 2.0. In general I am still very concerned about the failure to provide substantive recognition to the importance of web access for people with cognitive, language and learning limitations within the Guidelines. Below are my responses to your responses. Roger Hudson Web Usability Ph: 02 9568 1535 Mb: 0405 320 014 Email: rhudson@usability.com.au Web: www.usability.com.au -----Original Message----- From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] Sent: Sunday, 4 November 2007 4:09 PM To: Roger Hudson Cc: public-comments-WCAG20@w3.org Subject: Your comments on WCAG 2.0 Public Working Draft of May, 2007 ---------------------------------------------------------- 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) -------------------------------- Response to response -------------------------------- I don't feel that the examples you provide offer sufficient justification for doing away with the need to provide descriptive link text. A number of techniques could be used to avoid pages which have meaningful links being very cluttered where it is harder cognitively to find things. Your response includes the comment, "The working group recognizes that the link list mechanism provided by user agents and assistive technology will provide best results when SC2.4.8 is satisfied." But clearly, you don't recognise the importance of this sufficiently to put SC 2.4.8 should be at AA level, where I still believe it should be. ---------------------------------------------------------- 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. -------------------------------- Response to response -------------------------------- Your response to my comment appears to be based on an assumption that all web users are very technologically savvy. This is not the case, in my testing I have come across many users who don't have the knowledge or confidence to start changing browser and/or OS settings. Also, in some circumstances (e.g. some workplaces, libraries, and educational institutions) general access to these settings is blocked. It is my view SC 1.4.3 should be at Level A. ---------------------------------------------------------- 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. -------------------------------- Response to response -------------------------------- I appreciate your desire to see this bedded down before proceeding. However, in my understanding WCAG is not about historians who have a problem understanding chemistry, but is primarily concerned with improving access to the web for people with disabilities, including cognitive and reading disorders. I am more concerned with mundane things like making sure important words and phrases in documents like financial or insurance agreements can be understood by the widest possible audience. I look forward to development of new techniques and the day when the SC for this guideline is moved up to AA. ---------------------------------------------------------- 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. -------------------------------- Response to response -------------------------------- See my response to the comment above. I look forward to development of new techniques and the day when SC 3.1.4 is moved up to AA. ---------------------------------------------------------- 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. -------------------------------- Response to response -------------------------------- Many thanks. ---------------------------------------------------------- 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. -------------------------------- Response to response -------------------------------- I appreciate the difficulties you must have had in coming up with an appropriate conformance/scoring system. Thanks for spending the time to review this issue again. ---------------------------------------------------------- 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. -------------------------------- Response to response -------------------------------- This is the response to one of my comments that I am the most dissatisfied with since it still fails to address my real concern over the lack of support given to people with cognitive, learning and language limitations. I am pleased however to see that some of the suggested techniques may have contributed to a new Success Criterion relating to the presentation of blocks of text, but note that it is at Level AAA - i.e. the level that is least likely to be complied with. No amount of good-intention words relating to the importance of addressing the need of people with cognitive disabilities will replace the absence of a meaningful Success Criterion at either A or AA. When it comes to encouraging clients and developers to consider the needs of people with cognitive, learning and language difficulties, I am not sure WCAG 2.0 is any real advance on WCAG 1.0. I don't feel my suggested SC was too onerous. It suggested barriers to comprehension should be avoided but was deliberately not too prescriptive as to how this could be done. However, I think the suggested techniques provided a useful guide to the issues that should be considered when complying with the suggested SC. This combination of a specific Level AA Guideline and suggested techniques would I believe have helped underscore the significance of this issue with website developers and their clients. I feel that your comments relating to human testability when it comes to cognitive disabilities may just be a convenient way of avoiding the issue. If an image of a navigation item or a complex flow chart just had 'alt=picture',I would assume that the WG would not consider that this complied with the Guideline that requires the use of "a text alternative that presents equivalent information". Unless you are willing to accept vague img attributes such as this, it is likely to come down to humans to determine if the value of the attribute does actually present equivalent information. If a qualified human can determine whether or not a text description is an adequate alternative to an image, why do you feel it is not possible for qualified humans to determine if the complexity of a piece of text is such that an alternative way of presenting the information should be considered? ---------------------------------------------------------- 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. -------------------------------- Response to response -------------------------------- Let's see how CAPTCHAs play out, maybe with a bit of luck organisations will develop and use alternative ways to protect security and avoid the bad guys that are not so hard for people with some disabilities to use. If not, I hope the WG re-visits this issue in the near future.
Received on Sunday, 18 November 2007 22:37:19 UTC