- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:44:44 -0700
- To: "Jason White" <jasonw@ariel.its.unimelb.edu.au>
- Cc: public-comments-WCAG20@w3.org
Dear Jason White, 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: Consider extending this to cover the auditory presentation Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0143.html (Issue ID: 1939) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Success Criterion 1.3.3 Part of Item: Comment Type: technical Comment (Including rationale for any proposed change): Should this be extended to include auditory presentation, e.g., the sound of the content as presented in, for example, VoiceXML? Such an extension would surely be of benefit to people who are deaf in accessing Web-based voice/sound applications and similar content. For example, instructions such as \"The selected items are read in a male voice; unselected items are read in a female voice\" are unhelpful, even if the distinction between selected/unselected items in the user interface can be programmatically determined. Proposed Change: Consider extending this to cover the auditory presentation (i.e., sound) of the content. --------------------------------------------- Response from Working Group: --------------------------------------------- We agree that audio is an important sensory modality that needs to be captured, and others need not be left out. We have adjusted the provision as follows: 1.3.3 Sensory Characteristics: Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, size, visual location, orientation or sound. (Level A) ---------------------------------------------------------- Comment 2: Problems with CAPTCHA Clause Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0142.html (Issue ID: 1940) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Success Criterion 1.1.1 Part of Item: Comment Type: technical Comment (Including rationale for any proposed change): CAPTCHA: This success criterion is problematic. Even if both auditory and visual forms are provided, the content will remain inaccessible to users who are deaf blind. Furthermore, this lack of accessibility is not remedied at either level AA or level AAA of guideline 1.1, there being no success criteria at those levels. Cognitive CAPTCHA, e.g., arithmetic problems, can overcome the sensory difficulty noted above, while running the risk of raising barriers to people with cognitive disabilities. The only solution is to abandon CAPTCHA altogether, in favour of statistical filtering, e-mail confirmation or other security techniques as the situation demands. Given that services subject to CAPTCHA are often, from a practical point of view, significant, the result of the unfortunate compromise in guideline 1.1 is to exclude a significant group of users - those who are deaf blind - from important Web content. Proposed Change: Either require cognitive CAPTCHA, noting that it must be designed so as to minimize its adverse effect on users with cognitive disabilities, or, preferably, acknowledge that the CAPTCHA phenomenon is incompatible with accessibility, and hence incompatible with WCAG 2.0 conformance. While a Level AA success criterion excluding sensory CAPTCHA would be a welcome improvement to the current situation, it would still leave Level A-conformant content inaccessible to a significant group of users. Depending on the interpretation of WCAG 1.0, checkpoint 1.1, the current WCAG 2.0 draft is arguably a regression in that it offers less accessibility than is guaranteed by the 1.0 guidelines at level A, where no such limitation is admitted. --------------------------------------------- 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. ---------------------------------------------------------- Comment 3: when can an author assume a mechnism is available? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0144.html (Issue ID: 1941) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Success Criterion 1.4.2 Part of Item: Comment Type: question Comment (Including rationale for any proposed change): The definition of "mechanism", correctly in my opinion, makes it clear that a mechanism can be provided by user agents. It need not be provided by the author. Under what circumstances is an author entitled to assume that a mechanism to turn off the audio, or to regulate the volume, is available, assuming that it is not required to be implemented by any of the technologies included in the list of accessibility-supported Web technologies referred to in the author's WCAG 2.0 conformance claim? Note that control over the rendering of audio is required by UAAG 1.0 guidelines 3 and 4. Thus, if the author wants to assume that this is available, should this be achieved by including UAAG 1.0 in the list of accessibility-supported Web technologies, effectively specifying that a UAAG-conformant user agent is required in order for the content to meet WCAG 2.0? Proposed Change: --------------------------------------------- Response from Working Group: --------------------------------------------- Whether the use of a user-agent-provided mechanism is a sufficient technique will depend upon the accessibility support analysis for the technology in question. User agent notes for techniques reflect the working group's understanding of problems in support for the technique in different user agents. When the mechanism is not available in all user agents, the author must determine whether the user agents used by or available to his users all contain the appropriate support. If they do not, the mechanism cannot be relied upon. UAAG 1.0 would never be a candidate to be an accessibility-supported technology, since it is not a web content technology but a set of requirements on user agents. That is, one never "authors content in" UAAG 1.0. As more user agents satisfy UAAG 1.0, it should become easier for authors to comply with WCAG, since user agents will provide more the support needed for accessibility. However, authors cannot assume UAAG compliance, but must check the actual functionality of user agents used by or available to their users. ---------------------------------------------------------- Comment 4: Make it clear somewhere in the guidelines (perhaps the conformance section) that UI standards such as UAAG can be AsCT Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0147.html (Issue ID: 1942) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Success Criterion 2.4.1 Part of Item: Comment Type: technical Comment (Including rationale for any proposed change): The same problem that I raised regarding the availability of a "mechanism" in connection with sc 1.4.2 also arises here. If user agents support UAAG 1.0 structural navigation requirements then this sc (2.4.1) can be satisfied by providing proper structure in the content. However, given the wording of the "accessibility-supported Web technology" provisions in the Conformance section, it is far from clear that UAAG 1.0 can be specified in a published list of saccessibility-supported Web technologies, within the meaning of the WCAG 2.0 conformance requirements. Proposed Change: Make it clear somewhere in the guidelines (perhaps the conformance section) that user interface standards such as UAAG 1.0 can appear in published lists of accessibility-supported Web technologies, and that such lists are not limited to the technologies in which content is represented. --------------------------------------------- Response from Working Group: --------------------------------------------- Whether the use of a user-agent-provided mechanism is a sufficient technique will depend upon the accessibility support analysis for the technology in question. User agent notes for techniques reflect the working group's understanding of problems in support for the technique in different user agents. When the mechanism is not available in all user agents, the author must determine whether the user agents used by or available to his users all contain the appropriate support. If they do not, the mechanism cannot be relied upon. UAAG 1.0 would never be a candidate to be an accessibility-supported technology, since it is not a web content technology but a set of requirements on user agents. That is, one never "authors content in" UAAG 1.0. As more user agents satisfy UAAG 1.0, it should become easier for authors to comply with WCAG, since user agents will provide more the support needed for accessibility. However, authors cannot assume UAAG compliance, but must check the actual functionality of user agents used by or available to their users. ---------------------------------------------------------- Comment 5: Should this be applied to everything that qualifies as a "Web page"? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0148.html (Issue ID: 1943) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Success Criterion 2.4.2 Part of Item: Comment Type: technical Comment (Including rationale for any proposed change): Are you sure this can be applied, and ought to be applied, to everything that qualifies as a "Web page" under the definition? For example, how would this be applied to a multimedia object? A title could be included in the captions, but it isn't clear that captions count for purposes of satisfying this success criterion. Would the title have to be both presented as part of the multimedia and audio described or captioned? If I place a sound file on my Web site, it can qualify as a "Web page" under the definition, but it isn't obvious that I can meet this success criterion. If the sound file can include metadata, then perhaps providing a title in metadata would be adequate - but does this imply that audio formats that don't allow for metadata can't be used as part of a fully-conformant site? The same question arises in relation to images, which also qualify as Web pages if they are only linked to, not embedded as part of other resources. Even if metadata can be embedded in the sound/image file, there is no guarantee that the user can read it unless the specification of the format requires user agents to be able to display the metadata. It would appear that any interactive content providing a user interface can satisfy this success criterion by including a title as part of the user interface. Proposed Change: Perhaps this sc should be restricted to Web pages containing text, where "text" does not include images of text. This would also admit HTML pages containing only images, unless the presence of a text equivalent (under guideline 1.1) is sufficient to make the page "contain text" for the purpose of this proposal. Restricting this sc to cases where the technology specifically provides for the inclusion of titles (e.g., TITLE elements or equivalents) wouldn't work, as there are surely cases in which the technology doesn't provide for the identification of text as a title, but where it is still possible and desirable to provide a title. I suspect that this sc cannot remain at level A without restricting it to a subset of Web pages. --------------------------------------------- Response from Working Group: --------------------------------------------- The new guidelines allow items like this to be Web Pages as long as there is a Conforming Alternate Version. Therefore there are two ways to address these situations. 1) to embed the resource in a Web page that can conform 2) provide a 'conforming alternative version' Thus the working group believes it can and should remain at level A. ---------------------------------------------------------- Comment 6: Add requirements for live audio-only or live video-only content Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0149.html (Issue ID: 1944) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Guideline 1.2: Provide synchronized alternatives for multimedia Part of Item: Comment Type: technical Comment (Including rationale for any proposed change): The definition of "multimedia" correctly provides that multimedia content must be audio or video, synchronized with another format or involving time-based interaction. Audio-only and video-only content are not multimedia. Under sc 1.1.1, live audio-only and video-only content is required to be identified with a text equivalent. However, nowhere in guideline 1.1 or guideline 1.2 is it required to be accompanied by a text transcript, at any level of conformance; and pre-recorded audio-only and video-only content (not being multimedia) appear to escape coverage altogether. Thus, a radio station for example that provides transcripts of some of its content (and such transcripts do exist) isn\'t achieving a superior level of accessibility under WCAG than a radio station which does not provide such transcripts. Proposed Change: Under guideline 1.1 or guideline 1.2, at different conformance levels if necessary, provide for transcripts of both live and pre-recorded audio-only and video-only content. --------------------------------------------- Response from Working Group: --------------------------------------------- Response to Reviewer: Prerecorded audio-only and prerecorded video-only is covered by SC 1.1.1. Since it is not listed as one of the situations with special handling, there must be a text equivalent that presents equivalent information. Examples 2 and 3 of Examples of Success Criterion 1.1.1 demonstrate text equivalents for some audio-only and some video-only content. Because it is so difficult to provide text alternatives that convey the same information as live audio-only and live video-only content, only a descriptive label is required at Level A. We are aware of no techniques for providing text alternatives for live video-only content. We will be adding a technique for live audio-only content. ---------------------------------------------------------- Comment 7: Define "programmatically determined link context" more precisely Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0150.html (Issue ID: 1945) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Success Criterion 2.4.4 Part of Item: Comment Type: technical Comment (Including rationale for any proposed change): It isn't clear from the sc or the definition of "programmatically determined link context" how far around the link this context extends. If it is bounded by the next higher-level structural component of the content (e.g., the parent element of the link in the structure tree) then it is a different requirement than it would be under an interpretation, at the opposite end of the spectrum, whereby the whole page can qualify as the link context. The latter interpretation would tend to make the requirement trivial. Without a clearer specification of what the link context encompasses, it is difficult to evaluate the importance of this success criterion or to decide how much of an accessibility issue it presents. For instance, if the purpose of a link cannot be determined from a large portion of the page then that would be more of a difficulty to users than if it cannot be determined from the immediately enclosing structural element. Further, contrary to the suggestion in the editorial note, I don't think this issue should be characterized as presenting a problem for assistive technologies. Rather, it presents a problem to users as it determines how much associated context they have to read in order to discover the purpose or destination of a link. Proposed Change: Define "programmatically determined link context" in a more precise, testable way, before deciding on the priority of this success criterion. --------------------------------------------- Response from Working Group: --------------------------------------------- While the guidelines do not specify the scope of relationships to a link, relationships are defined to be meaningful, and the entire page would not meet that test. The Understanding SC 2.4.4 document explains that description of the link should be in the same sentence, paragraph, list item, or table cell as the link because these are directly associated with the link itself. This is based on the features of current user agents and is expected to evolve. ---------------------------------------------------------- Comment 8: Technologies that do not permit alternate versions Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0155.html (Issue ID: 1946) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Conformance Part of Item: Comment Type: technical Comment (Including rationale for any proposed change): The editorial note to conformance requirement 4 points out the difficulty that can arise with technologies which do not permit this requirement to be satisfied. Limitations regarding an author\'s content or server that can be removed by changing server-side configurations or altering content should not be regarded as constraints that prevent the implementation of this requirement however, as these can all be overcome (in the second case by changing the design of the content and in the first case by securing the cooperation of the server operator, if the server operator is not the author of the content). With these remarks having been made, however, there remains the possibility that a given technology, or combination of technologies, in which a Web page is written may not provide the necessary mechanism to meet requirement 4. This possibility is addressed in the following proposal. Proposed Change: If it turns out that some technologies do not permit requirement 4 to be met, then split the requirement into two alternative cases. Case 1: Where the technologies used to implement the non-conforming content support the provision of such a mechanism, stipulate that a mechanism of the kind stated in Requirement 4 as currently drafted, must be provided. Case 2: where requirement 4 as currently proposed cannot be met, specify the following weaker requirement: The non-conforming page is part of a set of Web pages, at least one of which provides a mechanism to obtain an alternate, conformant version. Obviously, this mechanism would itself have to satisfy conformance requirements, and the wording currently used to describe the mechanism captures this intent perfectly, and should be carried over into any revised draft. Note that the term "set of Web pages" is already defined in the glossary and used elsewhere in the guidelines, and thus can be employed here without introducing any new terminology or concepts. --------------------------------------------- Response from Working Group: --------------------------------------------- We have addressed the issue but not in the way you proposed. One of the key requirements is that people be able to find the conforming version from the inaccessible version. If the page will not support a link to the conforming version then it won't support a link to the other pages in the set, so if a person landed on the non-conforming page there would be no way to find the set of pages or the alternate conforming page. Instead, we simply require that their be either a conforming link or that there be some mechanism that is accessibility supported, which would allow the person to find the conforming page from the non-conforming page. ---------------------------------------------------------- Comment 9: Replace "forms" with "Web pages" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0151.html (Issue ID: 1947) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Success Criterion 3.3.3 Part of Item: Comment Type: technical Comment (Including rationale for any proposed change): This criterion should apply not only to "forms" (as in HTML forms or XForms) but also to other user interface technologies which, while not forms as such, nevertheless can be used to carry out transactions of the relevant kind. For instance, it should not be open for an author to argue that, because the content is implemented in an applet (or some other technology) rather than as HTML forms or XForms, the success criterion doesn't apply. Proposed Change: Replace "forms" with "Web pages". --------------------------------------------- Response from Working Group: --------------------------------------------- We have accepted your proposal and have changed "forms" to "Web pages" in 3.3.3 and 3.3.6 to avoid confusion with technology-specific uses of the word "form." ---------------------------------------------------------- Comment 10: clarify "is not embedded in another resource" Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0157.html (Issue ID: 1948) ---------------------------- Original Comment: ---------------------------- Document: W2 Item Number: Appendix A: Glossary Part of Item: Comment Type: technical Comment (Including rationale for any proposed change): In the definition of "Web page" the phrase "is not embedded in another resource" needs to be clarified. Consider for example an image, which (as is typically the case) has its own URI. It can be used in two ways: (1) by being embedded in, i.e., rendered together with, another resource. In this case it is not a Web page. (2) It can be linked to, or returned as the result of a user interface action, without being embedded in anything else. In this case it is a Web page by definition. What determines whether it counts as a Web page or not is how it is used. The ambiguity lies in the failure to specify what should be taken into account in ascertaining how a resource is used for the purpose of applying the definition. This has conformance-related consequences. Suppose for example that, on your Web site, a particular image is embedded in an XHTML document (using the IMG element or the SRC attribute of XHTML 2.0). For purposes of your conformance claim, it is embedded in another resource, and hence not a Web page. Assume further that on my Web site, the same image (at the same URI) is referenced, but only as a link, and is therefore not embedded in another resource. If we interpret the "not embedded in another resource" requirement as meaning "not embedded in another resource anywhere on the Web" then for purposes of the conformance claim covering my Web site, the image is not a distinct "Web page". However, if we interpret "not embedded in another resource" as applying only to a "set of Web pages" as defined in WCAG 2.0, then it appears that the image is a Web page for purposes of my conformance claim (because it's never embeded in any of my content), but is not a Web page for purposes of your conformance claim (as it is embedded in one of your other resources). Under this interpretation, it appears that my Web site will have conformance difficulties, if the image format does not support the inclusion of text alternatives, titles, etc., and the image thus cannot conform to WCAG 2.0 as an independent entity. The same problem arises if the image format does support text alternatives but you haven't supplied one in the image itself, whereas (let's assume) you have supplied one as part of the page in which the image is embedded. In both cases, the image is a "Web page" for purposes of my content, but not for purposes of yours, and my Web site as a whole doesn't conform to WCAG 2.0. However, if WCAG were to adopt the first interpretation mentioned above, whereby a resource is "not embedded in another resource" only when it is not so embedded anywhere whatsoever, then it appears that the conformance attained by my Web site, given the above scenario, now depends on whether anybody else's Web site embeds the image in another resource. Hence, the conformance of my site depends on other peoples' actions, totally unrelated to my content, and this doesn't seem satisfactory either. Proposed Change: I haven't thought of a good solution, since as shown above, both of the obvious answers have problems. Moreover, the kind of scenario that results in this difficulty could actually occur in practice: all that needs to happen for example is for one Web site to link directly to an image (or other embeddable resource) on another site, instead of linking to the page of the other site in which it is embedded. Follow up (from http://lists.w3.org/Archives/Public/public-comments-wcag20/2007May/0158.html) This is a follow-up regarding my earlier comment concerning "not embedded in another resource" (part of the definition of "Web page"). The scenarios I outlined can only occur where the same resource is within the scope of two distinct conformance claims. Having considered this furhter, I think it's reasonable to propose the following solution. Proposed Change: "Not embeded in another resource" means "not embedded in another resource covered by the same conformance claim", or wording to that effect. Note that if I place a resource (e.g., an image) on my Web site, make a conformance claim applicable to the whole site, and reference the image only in a link, without embedding it in any of my other resources, then the image will count as an independent Web page, and will be subject to all of the WCAG 2.0 conformance requirements at my chosen conformance level, even if the link text provides a text alternative. A resource that is linked to cannot be regarded as embedded, otherwise many resources that should count as Web pages would fail the definition simply in virtue of being linked to by other resources within the scope of the conformance claim. I think these consequences of the current definition, which are not affected by my proposal above, are tolerable; but it does appear that if a content author has a collection of images and refers to them only in links, it will be necessary for example to wrap each image in an HTML page to prevent it from being an independent Web page under the definition. --------------------------------------------- Response from Working Group: --------------------------------------------- Thank you for this exploration of this issue. We have amended the definition of Web page to say: Web page a non-embedded resource that is referenced by a URI plus any other resources that are used in the rendering or intended to be rendered together with it by a user agent Note 1: Although any "other resources" would be rendered together with the primary resource, they would not necessarily be rendered simultaneously with each other. Note 2: For the purposes of conformance with these guidelines, a resource must be "non-embedded" within the scope of conformance to be considered a Web page. Example 1: A Web resource including all embedded images and media. Example 2: A Web mail program built using Asynchronous JavaScript and XML (AJAX). The program lives entirely at http://example.com/mail, but includes an inbox, a contacts area and a calendar. Links or buttons are provided that cause the the inbox, contacts, or calendar to display, but do not change the URL of the page as a whole. Example 3: A customizable portal site, where users can choose content to display from a set of different content modules. Example 4: When you enter "http://shopping.example.com/" in your browser, you enter a movie-like interactive shopping environment where you visually move about a store dragging products off of the shelves around you into a visual shopping cart in front of you. Clicking on a product causes it to be demonstrated with a specification sheet floating alongside.
Received on Sunday, 4 November 2007 04:45:08 UTC