- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:28:47 -0700
- To: "Charles McCathieNevile" <chaals@opera.com>
- Cc: public-comments-WCAG20@w3.org
Dear Charles McCathieNevile , 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/op.tbjlv1aowxe0ny@researchsft.myhome.westell.com (Issue ID: LC-1302) Technical/substantive issue The section currently provides no guidance to actually choosing a baseline that can in fact be used accessibly. I propose that the availability of a user agent which meets level-A conformance to User Agent Accessibility Guidelines 1.0 for the relevant technology and language be a minimum criterion for the selection of a baseline. In this way, selection of a baseline that is not actually accessible automatically makes it impossible to claim conformance to the accessibility guidelines. This avoids the situation where it is possible to construct content that can meet the requirements, but that is not actually accessible due to the absence of any means for using the baseline set. Otherwise there is a risk that the value of conformance will be significantly reduced, since it makes no reliable statement about whether the content is in fact accessible to real people. This seems a reasonable requirement given that UAAG is a W3C recommendation, and does not seem onerous for common web technologies. cheers Chaals ---------------------------- Response from Working Group: ---------------------------- For a period, WCAG made the assumption that user agents satisfied UAAG. This would have simplified a number of issues. However, in the absence of any user agent for any technology that is fully UAAG-compliant, the working group did not think it was practical to require only the use of technologies for which such user agents exist. The effect of such a requirement would be to make it impossible to claim compliance for any web content. The notion of baseline (now accessibility-supported web technologies) was introduced to make it possible to apply WCAG in environments with a wide range of user agent support for accessibility. It places a much heavier burden on the author to understand the capabilities of his customer's user agents. WCAG will be much easier to satisfy in an environment in which UAAG is satisfied by the available user agents. ---------------------------------------------------------- Comment 2: Source: http://www.w3.org/mid/op.tbjlv5miwxe0ny@researchsft.myhome.westell.com (Issue ID: LC-1303) Structural/substantive issue The current levels system for success criteria seems insufficiently described, and inappropriate to the needs of developers. WCAG 20 acknowledges that most criteria are essential in order for some people to be able to use some types of web content. It then attempts to describe the amount of benefit to usersin general (the difference between level 1 and level 2) and the apparent applicability of a technique to the web. It appears that the goal is to provide a "reasonable" implementation planning tool. Both of these things are in fact situation-dependent. In some cases, it will be easy, in others critical, to apply approaches whose level suggests that they are not so important or easy in the general case. Thus, while providing a signed equivalent of content is extremely important in a number of cases, and is occasionally trivially easy (in others it is quite expensive), it is perfectly possible that all web content claiming triple-A conformance is without signed content. Similarly, there is no clear technical justification for different requirement levels for captioning depending on whether content is "live"/"real-time", or pre-recorded. The accesibility result for users who rely on captions is exactly the same in both cases. Again, this may be easy to implement in some cases, and is very expensive in others, and its relative importance will be variable. In order to assist developers, and policy makers, WCAG should describe the imact on users of a particular success criterion being met or not. This enables prioritisation based on the actual situation, rather than a generalised model situation which will often be an inaccurate representation of the case at hand. I propose that either: 1. the levels be removed, and the information in the currently informative "Understanding WCAG" about who benefits be moved to the normtive recommendation. Or, as an alternative 2. the specification revert to the WCAG 1.0 priority scheme, rather than with the "apparent ease of implementation" clouding the question of their relevance to users. cheers Chaals ---------------------------- 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. ---------------------------------------------------------- Comment 3: Source: http://www.w3.org/mid/op.tbjxedeqwxe0ny@researchsft.myhome.westell.com (Issue ID: LC-1307) Structural/substantive issue The specification seems to take no account of situations where in fact all user agents relevant to a given baseline offer functionality that the guidelines are requiring of authors. Where this is the case (for example, SVG user agents generally provide a mechanism to pause any animation independently of the content, and in SVG tiny it is not possible to provide the functionality in content anyway) the guidelines should take it into account. I propose that the baseline section be reworked, to incorporate this type of situation. Perhaps the most robust way of specifying this would be to explicitly relate UAAG requirements to WCAG requirements, and note that where there are (some expression for most or all) user agents for the baseline which meet a given UAAG requirement the corresponding WCAG requirement need not be met. Note that the proportion of user agents for which this needs to be true should be at least as high, and probably higher than that which is reasonable to justify the use of a particular baseline in the first place. ---------------------------- Response from Working Group: ---------------------------- WCAG success criteria have been written to describe the functionality that must be available, but have avoided specifying that the functionality must be provided by the user agent or by the content directly. For example, SC 2.4.1 (A mechanism is available to bypass blocks of content that are repeated on multiple Web pages) can be satisfied by providing links in the content to bypass the blocks, or by providing headings at the beginning of each section and relying on the user agent to skip the repeated content by skipping to headings. ---------------------------------------------------------- Comment 4: Source: http://www.w3.org/mid/op.tbjxeubjwxe0ny@researchsft.myhome.westell.com (Issue ID: LC-1308) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006Jun/0169.html In the current framework, while there are success criteria there are no normative explanations of how they apply to given technologies. Instead, understanding WCAG 2.0 has been made an informative document. This is inappropriate to ensure interoperability of tools and content. This has been a major problem with the implementation of WCAG 1.0, where important questions of interpretation (such as "are tables OK for layout?", "do all user agents identify form fields without default text in them?", "is it OK to rely on javascript?", "are px units OK for layout?" among others) have gone unanswered for many years leading to a major breakdown in interoperability between tools, services, and content itself. I propose that the information be made available in a normative document. The process requirements for publishing such a document would seem to be very lightweight in the context of how long it takes the WCAG group to determine necessary changes, and this will at least ensure that an authorative answer becomes available for issues which arise. cheers Chaals ---------------------------- Response from Working Group: ---------------------------- It has been challenging to write success criteria that are technology neutral, testable, and easy to understand. We have taken great pains to write the success criteria so that it would be clear which techniques would or would not pass to experts. We are using the Understanding document to make it clear for those who are not experts. However, we don't want to restrict the range of solutions by making the list of known solutions normative. We do not believe that we could update normative Understanding and Technique documents quickly enough to keep pace with the changes in technologies and user agents. The W3C process is long for any document. This approach also allows WCAG 2.0 to avoid introducing some of the "until user agent" problems from WCAG 1.0. ---------------------------------------------------------- Comment 5: Source: http://www.w3.org/mid/op.tbjxeqrswxe0ny@researchsft.myhome.westell.com (Issue ID: LC-1309) The guidelines place in level 3 very many of the requirements necessary to help people with cognitive and reading disabilities access the web. Since only 50% of level 3 requirements (as chosen by content authors) need to be met in order to claim confomance to the guidelines, it is quite possible to conform to the guidelines at triple-A level while doing very little (and clearly not enough) to address the needs of these user groups. I propose either that this be explicitly and clearly explained in the introductory and conformance sections, or that the levels system be reworked as per my lat call comment on them. cheers Chaals ---------------------------- Response from Working Group: ---------------------------- We have changed the definition of Triple-A conformance so that all level AAA success criteria must be satisfied. We have added language to the Introduction, the Conformance section, and the Quick Reference to highlight the fact that WCAG 2 only addresses some of the needs of people with cognitive, learning, and language disabilities, and to call out the need for more research in this area. WAI is exploring ways in which to support and encourage work in this important area. In addition, we have added some best practices for cognitive, learning, and language disabilities as advisory techniques, and we have proposed 3 new success criteria in this area. ---------------------------------------------------------- Comment 6: Source: http://www.w3.org/mid/op.tbly4lvhwxe0ny@researchsft.myhome.westell.com (Issue ID: LC-1320) Technical/substantive issue? The current requirement fo unambiguous parsing is impossible to meet - there are always multiple ways of parsing any data. Instead I suggest the old wording of "conforms to formal published grammars". This makes it feasible for User Agents to recognise the content and parse it either according to the rules for such grammars, or in cases where it is necessary (such as HTML) to use specifically adapted parsing techniques. cheers Chaals ---------------------------- Response from Working Group: ---------------------------- To make this requirement easier to understand, we have reworded SC 4.1.1 as follows: 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. Note: Start and end tags that are missing a critical character in their formation, such as a closing angle bracket or a mismatched attribute value quote are not complete. 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.
Received on Thursday, 17 May 2007 23:29:14 UTC