- From: Gian Sampson-Wild <gian@tkh.com.au>
- Date: Sun, 24 Jun 2007 22:57:31 +1000
- To: "'Loretta Guarino Reid'" <lorettaguarino@google.com>
- Cc: <public-comments-WCAG20@w3.org>
Hi Loretta It is easier to respond to each issue per email so you will be getting a lot of emails in the next few hours about these. Cheers, Gian -----Original Message----- From: Loretta Guarino Reid [mailto:lorettaguarino@google.com] Sent: Friday, 18 May 2007 9:47 AM To: Gian Sampson-Wild Cc: public-comments-WCAG20@w3.org Subject: Your comments on WCAG 2.0 Last Call Draft of April 2006 (1 of 8) Dear Gian Sampson-Wild , 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/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1062) 4.1.2: What is the "name" or the "role"? What does it mean "values can be set by the user"? Proposed Change: Rewrite SC 4.1.2 ---------------------------- Response from Working Group: ---------------------------- The terms "name" "role" and "programmatically set" are each defined in the glossary. How to Meet SC 4.1.2 describes the intent of this success criterion and provides techniques about how to meet it. With regard to your suggestion to rewrite 4.1.2, without more information about the problems you see with this provision or specific suggestions for how to rewrite this criterion, we are unsure how to address your comment. ---------------------------------------------------------- Comment 2: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1020) Issues with commenting - It is difficult to accurately comment on WCAG2 when the documents that are needed to understand WCAG2 are not normative and are not complete. For example, one cannot interpret a SC without referring to techniques, yet these are not normative. There has been a lot of people saying WCAG2 is difficult to understand, yet they cannot rely on the UW or TD documents as these are neither normative or complete. The WG could vote to significantly change these documents, thereby significantly changing the meaning of particular success criteria, without ever allowing comments from the public. In a perfect world neither the UW or TD documents would be required in order to understand WCAG2 but taking into account the difficulty most people are having with interpreting WCAG2, these documents are becoming mandatory reading. Proposed Change: Allow for a subsequent 'Last Call' when all documents are complete, and specify that WCAG2 must be read and interpreted in conjunction with UW and TD documents ---------------------------- Response from Working Group: ---------------------------- In order to be technology neutral but accurate and testable the guidelines themselves need to be written in language that sometimes can be abstract or technical. We recognize that this can make them difficult to understand. We have spent much time trying to figure out how to make them as simple to understand as possible while keeping them accurate and clear. We have also been very careful to be sure that the guidelines themselves contain what is required. Information in the non-normative documents can never require anything that is not already required by the language in the normative document. Thus the guidelines can stand on their own in terms of 'interpretability'. However we have also created extensive support documentation to help make them easier to understand and to include examples and specific techniques for meeting them. The Understanding WCAG documents and techniques documents will continue to evolve because technologies and user agent support continue to evolve, so that new sufficient techniques can emerge as assistive technology and other user agent support improves over time. It is important that these documents remain non-normative so that they can be changed as our collective knowledge grows. It is very useful to read the ancillary documents to better understand the document. The ancillary materials may aid comprehension but are not in fact normative. The ancillary materials have been filled in since the time of the comment, and while not fully complete, are being republished at the same time in order to provide non-normative explanatory information to aid comprehension. ---------------------------------------------------------- Comment 3: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1021) Cognitive disabilities - People with cognitive disabilities are unfairly discriminated against within WCAG2. I believe this is due to the usability and testability requirements. It is generally accepted (and one chair has said so explicitly) that requirements that assist people with cognitive disabilities are often general usability techniques. Criteria that assist people with cognitive disabilities is more likely to fall foul of the requirement for testability than other criteria, simply because these criteria recommend changes to the way content is written, not how a site is coded. For example, in WCAG1 Checkpoint 14.1 - Use the clearest and simplest language appropriate for a site's content - still has no clear equivalent in WCAG2 and partiallymaps to Level 3success criteria. Proposed Change: Set up a specific taskforce within WCAG WG to identify success criteria that should be added to ensure WCAG2 addresses the needs of people with cognitive disabilities (I volunteer to be a part of, or to head up, this taskforce), or comply with Lisa Seeman's suggestions in her formal objection (which I have cosigned) ---------------------------- Response from Working Group: ---------------------------- 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. 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 4: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1022) Testability - The decision to comply with the testability requirement has outlawed some very important success criteria. This requirement has also not been applied fairly to all success criteria. Some current success criteria do not comply with the 8 out of 10 rule - for example 1.1.1. This SC requires that alternatives to non-text content "serve the same purpose and present the same information". One basic example of this is to require equivalent ALT attributes for images, but I do not believe that 8 out of 10 people would agree on the same ALT attribute for an image. For instance, in the Live in Victoria site (www.liveinvictoria.vic.gov.au) there is an image under the heading "Business Migrants". When I worked on this site, several people said this image should have a null ALT attribute as it conveyed no information. Several other people suggested ALT attributes of "A couple of business migrants chatting at work" or "Guys chatting at work". Whereas the ALT attribute that I recommended was "There is a wealth of opportunities for Business Migrants in Victoria." Proposed Change: Remove the requirement for testability and set up a taskforce (I volunteer to work on or head up this taskforce) to identify criteria that should be included in WCAG2. Alternatively, develop a set of supplementary guidelines that are non-testable to be used in conjunction with WCAG2. ---------------------------- Response from Working Group: ---------------------------- The success criteria need to be testable or else people cannot tell when they have conformed to the success criteria and thus WCAG 2.0. With regard to SC 1.1.1 the success criterion does not require that ALT text provided by different people be the same. WCAG 2.0 categorizes different classes of alt text and provides test procedures to help humans evaluate whether alt text satisfies the success criterion. Advisory techniques are used to provide supplemental materials that are non-testable that can be used in conjunction with WCAG 2.0. They provide additional guidance on what can be done beyond the requirements of WCAG. ---------------------------------------------------------- Comment 5: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1023) AAA conformance - It is not clear how one achieves AAA conformance. In the WCAG 2.0 document (under the 'Conformance' heading) there is a note "Because not all level 3 success criteria can be used with all types of content, Triple-A conformance only requires conformance to a portion of level 3 success criteria". Does this mean a site can claim Triple-A conformance if they comply with all Level A and Level AA SC and one Triple-A SC? This statement is in contradiction with information in the "Baseline" document which states (under the 'Vertical and Horizontal scoping in conformance statements' - first question) "Any web content for which Level AAA conformance is claimed must meet all Level 1 and Level 2 success criteria plus at least 50% of applicable Level 3 success criteria". Proposed Change: Firstly, there must be consistency between the two documents and how to claim AAA conformance must be clearly detailed. I do not understand why AAA is being treated differently to A and AA. I believe AAA compliance should mean compliance with all AAA SC, not just ones the developer chooses to implement. ---------------------------- Response from Working Group: ---------------------------- We have changed the definition of Level AAA conformance so that all Level AAA Success Criteria that apply to the content types used must be satisfied. ---------------------------------------------------------- Comment 6: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1024) Conformance schema - The decision to remove the design requirement from Level 1 has meant there is no appreciable difference between Level 1 and Level 2. I recall many instances where SC were moved to L2 because of this design requirement, yet I have not seen any indication that these SC are being moved back in to L1. Proposed Change: Merge Level 1 and Level 2 SC into one group called "Mandatory". Rename Level 3 to "Advisory" or "Optional" Alternatively set up a taskforce (which I volunteer to be a part of, or head) to review L2 and L3 SC to see if they can be moved to L1. ---------------------------- Response from Working Group: ---------------------------- The working group feels that there are three categories of success criteria, so we have retained three levels of conformance. The description of conformance levels in WCAG 2 has been rewritten to clarify the levels (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 7: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1026) Conformance schema - The documents say that all success criteria are essential to people with disabilities (see WCAG 2.0 under 'Conformance' - "The WCAG WG believes that all SC ..."), however by using the WCAG1 labelling system this change is not obvious. In addition to this, the Conformance section specifically states a hierarchical nature to the to the SC in WCAG2 by defining Level 1 as "achiev(ing) a minimum level of accessibility", Level 2 as "achiev(ing) an enhanced level of accessibility" and Level 3 as "achiev(ing) additional accessibility enhancements". The Conformance section is contradictory, because in the subsequent paragraph it says "Each checkpoint in WCAG 1.0 was assigned a "priority" according to its impact on accessibility... the system of checkpoints and priorities used in WCAG 1 has been replaced...". By using the subjective terms Priority 1 / A in WCAG2, the WG is implying that there is a hierarchical nature to the SC. People are used to the WCAG1 labelling system and will assume that by following all Level A SC that they are creating an accessible web site. Proposed Change: Merge Level 1 and Level 2 SC into one group called "Mandatory". Rename Level 3 to "Advisory" or "Optional" ---------------------------- Response from Working Group: ---------------------------- The working group feels that there are three categories of success criteria, so we have retained three levels of conformance. The description of conformance levels in WCAG 2 has been rewritten to clarify the levels. See http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels. ---------------------------------------------------------- Comment 8: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1027) Definition of accessibility - In the Baseline document (under the heading 'If the WCAG does not set the baseline, then how can we be sure that a site will be accessible?) it says "No site or content is ever completely accessible". In the Conformance document it says "Note that even conformance to all three levels will not make web content accessible to all people." I strongly object to these statements. All content can be made accessible. In some cases, content may not be accessible, but if the problems were identified it could be made accessible. As the main body representing accessibility I think it reprehensible that we have these statements. Proposed Change: Remove the statements. Merge Level 1 and Level 2 SC into one group called 'Mandatory'. Rename Level 3 to 'Advisory' or 'Optional' ---------------------------- Response from Working Group: ---------------------------- The statements you refer to are meant to reflect the reality that not all Web content can be made accessible to all people. One of the lessons learned with WCAG 1.0 was that, for some individuals, even content that meets WCAG 1.0 AAA did not overcome the accessibility barriers faced by those with certain combinations of disabilities or with certain types of severe disabilities. Regarding the proposal to combine levels A and AA as mandatory and rename level AAA to advisory or optional, the working group has received a great deal of feedback on both sides of this issue. We have chosen three levels because we feel it provides the best options for the different users of the guidelines. ---------------------------------------------------------- Comment 9: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1028) Baseline - From reading the Baseline documents, it appears that if a baseline technology does not have particular functionality (for example, the ability to navigate using only the keyboard), then the site can still be compliant with WCAG2 (but obviously not accessible). I think it is reprehensible that the main body advocating accessibility is about to release a set of guidelines that patently allow inaccessible web sites. Proposed Change: Remove the baseline theory, or allow only UAAG compliant programs in baseline. ---------------------------- Response from Working Group: ---------------------------- Your concern seems to arise from a different understanding of the meaning of Baseline than that intended by the Working Group. To help address this the conformance section has been completely rewritten, and the term "baseline" has been replaced by "accessibility-supported Web technologies". In order to claim conformance, a Web page must satisfy the WCAG success criteria using a technology that has assistive technology support and works with the accessibility features in user agents. If a technology does not have a particular functionality that is necessary to satisfy some WCAG success criterion (such as keyboard support), then it is impossible to create a conforming Web page relying on that technology. The page would need to meet that success criterion using one of the other technologies upon which it relies. NOTE: The technologies referred to are not the user agents, so they couldn't conform to UAAG. They are the technologies used to build the page (like HTML, CSS etc.) The question of whether a technology is accessibility supported is affected by the behavior of user agents and assistive technology for the technology. ---------------------------------------------------------- Comment 10: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1029) Baseline - From reading the Baseline documents, it appears that if a baseline technology does not have particular functionality (for example, the ability to navigate using only the keyboard), then the site can still be compliant with WCAG2 (but obviously not accessible). This acts as a disincentive for big corporations to develop accessibility features. Developers want things to be easy - it's a lot easier to click "Print to PDF" in a Word document than it is to tag a PDF. So what is to stop Adobe (sorry Loretta!) superceding their PDF technology with a new "SDF" technology that has no accessibility features? In that case it would be a lot easier for a person to create a WCAG2 compliant SDF document than it would be to create a WCAG2 compliant PDF document. In another example, if someone had CSS in their baseline then it would be WCAG2 compliant to use CSS markup to highlight a specific word without having an HTML alternative, and which would not be able to be interpreted by a screen reader Proposed Change: Remove the baseline theory, or allow only UAAG compliant programs in baseline. If I have misinterpreted the baseline theory, then the WG needs to develop a document to be used in conjunction with WCAG2 that lists what baseline technologies must be able to do (similar to UAAG) ---------------------------- Response from Working Group: ---------------------------- The conformance section has been completely rewritten, and the term "baseline" has been replaced by "accessibility-supported Web technologies". If a technology doesn't have AT support then you can't use that technology to meet WCAG according to our conformance requirements. So the problem you cite would be covered. Determining whether a technology is accessible-supported is based on the availability and support for that technology in users' user agent and AT. The purpose is to ensure that content can be accessed with the user's AT. NOTE: The technologies referred to are not user agent technologies. They are the technologies used to build the page (like HTML, CSS etc.) ---------------------------------------------------------- Comment 11: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1030) Baseline - Baseline needs to be defined, just like all other terms in WCAG2. There is no specific definition Proposed Change: Provide a definition for baseline ---------------------------- Response from Working Group: ---------------------------- The conformance section of WCAG2 has been completely rewritten. The term "baseline" has been replaced by "accessibility-supported Web technologies". The issue of what it means to be an accessibility-supported Web technology is addressed in the section "Accessibility Support of Web Technologies" at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support . ---------------------------------------------------------- Comment 12: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1031) Baseline - Under "Examples of People and Places setting baselines" it says baseline includes only technologies supported by "accessible and affordable user agent(s)". What is the definition of "affordable"? I believe this is advocating technology preference. For instance, if Microsoft created a proprietary technology that only worked only on IE, which came bundled with new versions of Windows, then it could be argued that that proprietary technology could be included in a baseline. The W3C should not be in the advocating anything that supports large corporations taking over the web Proposed Change: Remove the baseline theory, or allow only UAAG compliant programs in baseline. ---------------------------- Response from Working Group: ---------------------------- The conformance section of WCAG2 has been completely rewritten. The term "baseline" has been replaced by "accessibility-supported Web technologies". The issue of what it means to be an accessibility-supported Web technology is addressed in the section "Accessibility Support of Web Technologies" at http://www.w3.org/TR/2007/WD-WCAG20-20070517/#accessibility-support . ---------------------------------------------------------- Comment 13: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1032) Baseline - All the reasons why the WG left the definition of baseline up to the developers (or governing bodies) could also be used as reasons why the WG have developed an updatable document on technologies with enough accessibility features to be in baseline. The fact that there are no user agents that comply with UAAG is an obvious indication that there are no technologies (yet) that are as accessible as HTML and CSS. I believe it is reckless to leave this decision up to developers or managers whose focus is on the bottom line, not on providing accessible web sites. Proposed Change: Develop a document, for use with WCAG2, that list suitable technologies for baseline. This document can be updated by the WG or the W3C every year. ---------------------------- Response from Working Group: ---------------------------- Note that HTML and CSS are also technologies for which there are not yet fully UAAG-compliant user agents, so this doesn't seem like an argument that they are more accessible. However, they are supported by a wider set of user agents and assistive technologies, which is why we would expect them to be considered accessibility-supported content technologies in more contexts than other technologies. WAI will provide some examples of analyzing the user agent and assistive technology support for several Web technologies, to evaluate whether they satisfy these requirements. However, WAI is not in a position to evaluate what user agents and assistive technologies are available in different environments. We would encourage experts in those technologies in different locales to develop reference information for Web site authors. ---------------------------------------------------------- Comment 14: Source: http://www.w3.org/mid/000901c69538$2e394450$f4c9b23a@tkhcomputer (Issue ID: LC-1033) Baseline - Under "Examples of baselines and what they mean" (example 1) it says "The baseline includes HTML 4.01, in addition to GIF and JPEG images. this extremely limited baseline.". I object to the use of the words "extremely limited" - it is a deliberately pejorative statement Proposed Change: Remove the words "extremely limited" ---------------------------- Response from Working Group: ---------------------------- The words have been removed. They are no longer used in WCAG.
Received on Sunday, 24 June 2007 12:58:03 UTC