- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:37:52 -0700
- To: "John Nissen" <jn@cloudworld.co.uk>
- Cc: public-comments-WCAG20@w3.org
Dear John Nissen , 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/20060606062005.578DCBDA9@w3c4.w3.org (Issue ID: LC-734) Part of Item: Comment Type: GE Comment (including rationale for proposed change): [See http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0151/WCAG_comment.doc for original comments.] I am concerned about 4.2.2, point 1, as regards both (a) ease of comprehension (in particular in the use of "entered" when concerned with "content") and (b) effectiveness (in case the user can be "trapped" through other means). In the comparison document, http://www.w3.org/TR/WCAG20/appendixD.html, we have: And if all else fails (Priority 1) WCAG 2.0 Success Criteria 11.4: If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page. 4.2.1 At least one version of the content meets all level 1 success criteria, but alternate version(s) that do not meet all level 1 success criteria may be available from the same URI. (Level 1) 4.2.2 Content meets the following criteria even if the content uses a technology that is not in the chosen baseline: (Level 1) 1. If content can be entered using the keyboard, then the content can be exited using the keyboard. 2. Content conforms to success criterion 2.3.1 (general and red flash). In the "Understanding" document, http://www.w3.org/TR/UNDERSTANDING-WCAG20/, we have: How to Meet Success Criterion 4.2.2 4.2.2 Content meets the following criteria even if the content uses a technology that is not in the chosen baseline: (Level 1) 1. If content can be entered using the keyboard, then the content can be exited using the keyboard. 2. Content conforms to success criterion 2.3.1 (general and red flash). Key Terms content information to be communicated to the user by means of a user agent Note: This includes the code and markup that define the structure, presentation, and interaction, as well as text, images, and sounds that convey information to the end-user. baseline set of technologies assumed to be supported by, and enabled in, user agents Note: For more information on baselines and their use, refer to Technology Assumptions and the \"baseline.\" Intent of this success criterion The intent of this success criterion is to ensure that content which uses technologies outside the baseline does not include components that actively interfere with the accessibility of the remaining content. Such components include: • components that would trap keyboard users within inaccessible content. • flashing components that could cause seizures due to photosensitivity \"Keyboard trapping\" refers to a common situation in which the keyboard focus can become stuck in inaccessible plugins, leaving a keyboard-only user with no way to return to the accessible content. The requirement that content that can be entered via the keyboard can be exited via the keyboard is to prevent this \'lock up\' effect. The requirement to satisfy Success Criterion 2.3.1 is intended to ensure that users with photosensitivity (including users who may not be aware of their vulnerability) do not encounter flashing content that could cause a seuzure. Content may be implemented in technologies that are not in the baseline if accessible alternatives are provided using technologies that are in the baseline, or if the content is accessible from a user agent that supports only the technologies in the baseline. It is vital that there be no characteristics of any of the content that actively interfere with its accessibility. This is because user agents that support the technology used could be present and create accessibility problems even though the technology is not part of the baseline. In the techniques document, http://www.w3.org/TR/2006/WD-WCAG20-TECHS-20060427/Overview.html#G21 we have: G21: Ensuring that users are not trapped in content Applicability All technologies which support interactive operation. This technique is referenced from: • How to Meet Success Criterion 2.1.1 • How to Meet Success Criterion 4.2.2 Description The objective of this technique is to ensure that keyboard users do not become trapped in a subset of the content that can only be exited using a mouse or pointing device. A common example is content rendered by plug-ins. Plug-ins are user agents that render content inside the user agent host window and respond to all user actions that takes place while the plug-in has the focus. If the plug-in does not provide a keyboard mechanism to return focus to the parent window, users who must use the keyboard may become trapped in the plug-in content. This problem can be avoided by using one of the following mechanisms to provide a way for users to escape the subset of the content: • Ensuring that the keyboard function for advancing focus within content (commonly the tab key) exits the subset of the content after it reaches the final navigation location. • Providing a keyboard function to move the focus out of the subset of the content. Be sure to document the feature in an accessible manner within the subset. • If the subset of the content does natively provide a \"move to parent\" keyboard command, documenting that command before the user enters the plug-in so they know how to get out again. Examples • Once a user tabs into an applet, further tabs are handled by the applet preventing the person from tabbing out. However, the applet is designed so that it returns keyboard focus back to the parent window when the person finishes tabbing through the tab sequence in the applet. My concerns are over comprehension and effectiveness. (a) Concern over comprehension The use of the word "entered" in connection with "content" suggests that the user is entering text, for example entering text into a field of a form (such as search terms into Google). It is clear from the "Understanding" document that "entering" refers to entering a part of the page (i.e. subset of the content). Therefore I suggest changing the point as follows: 1. If a part or subset of the content (using a technology that is not in the chosen baseline), can be entered using the keyboard, then that part or subset can be exited using the keyboard. (b) Concern over effectiveness It is not at all obvious that this is about trapping, nor that it is effective against trapping in general. (For example, I could envisage being trapped by a pointing device if there were no way to exit using the pointing device.) So I would like to see the point made more explicit and more general by a further change as follows: 1. If a part or subset of the content (using a technology that is not in the chosen baseline), can be entered using some device (such as the keyboard), then that part or subset can be exited using the same device, such that a user cannot be trapped in that part without a means to exit. Furthermore, the effectiveness relies on the means of exiting being documented in such a way that it is obvious to the user how to escape. So I suggest adding the word "obvious" to the above: 1. If a part or subset of the content (using a technology that is not in the chosen baseline), can be entered using some device (such as the keyboard), then that part or subset can be exited using the same device, such that a user cannot be trapped in that part without an obvious means to exit. Proposed Change: ---------------------------- Response from Working Group: ---------------------------- Thank you for pointing out the ambiguity in the use of the word "entered". To clarify, we have adapted your proposal and changed conformance requirement 6, item 1, as follows: "If focus can be moved to technologies that are not accessibility supported using a keyboard interface, then focus can be moved away from that content using only a keyboard interface, and the method for doing so is described before the content is encountered and in a way that meets all Level A success criteria." Although making the means to exit obvious to the user is important to the effectiveness of any technique, we are unable to determine any way to test whether a technique is obvious, since it depends upon the user's expectations. The technique "Ensuring that users are not trapped in content" discusses the need to document the mechanism. ---------------------------------------------------------- Comment 2: Source: http://www.w3.org/mid/16a201c680ce$efd26840$0202a8c0@Tomschoice (Issue ID: LC-1331) Dear Chair and members of WAI, I would like to suggest some improvement in 4.2.2. I have documented my proposal, and the reasons for it, in the attached document. I have to admit that at first reading of 4.2.2 (point 1), I was completely flumoxed. But having read through a lot of explanation, I think you could make the point a lot clearer and also more effective by some small changes. BTW, I notice that the deadline for comments is 31st May, and I shall be out next week for half-term holiday! So if there is a problem with this submission, please let me know by return. Yours sincerely, John [See attachment to http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0151 ] ---------------------------- Response from Working Group: ---------------------------- Thank you for pointing out the ambiguity in the use of the word "entered". This success criterion has been moved to conformance. To clarify, we have adapted your proposal and changed conformance requirement 6, item 1, as follows: "If focus can be moved to technologies that are not accessibility supported using a keyboard interface, then focus can be moved away from that content using only a keyboard interface, and the method for doing so is described before the content is encountered and in a way that meets all Level A success criteria." Although making the means to exit obvious to the user is important to the effectiveness of any technique, we are unable to determine any way to test whether a technique is obvious, since it depends upon the user's expectations.
Received on Thursday, 17 May 2007 23:38:11 UTC