- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:34:36 -0700
- To: "Greg Lowney" <gcl-0039@access-research.org>
- Cc: public-comments-WCAG20@w3.org
Comment 15: Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13 (Issue ID: LC-1160) 1.3.5 says information required to operate the content should not rely on visual location or orientation of components, but in HTML forms the association between a control (e.g. radio button) and its visual label (e.g. static text nex to it) are only exposed programmatically through the DOM and visually by the spatial relationship between the two objects. The only way to avoid relying on spatial cues is to use assistive technology; is that the intention of this criterion, even though the word "programmatically" does not appear in the wording and the Understanding and Techniques don't explicitly mention steps to assist assistive technology? ---------------------------- Response from Working Group: ---------------------------- The success criterion has been reworded to make it clear that it is about instructions to the user that use spatial referents. Form labels are therefore excluded from the requirements of this SC. ---------------------------------------------------------- Comment 16: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1161) 1.4.1 specifies a minimum luminosity contrast between text or diagrams and their backgrounds. Often diagrams include portions that convey information and other portions that are purely decorative; in such cases, shouldn't this criterion apply only to portions of the text or diagram that are functional or convey information? Large text used as a decorative element behind the text of a Web page is an example of purely decorative text, and in such cases you really need to retain low contrast with the background. Proposed Change: Change to read "Portions of text or diagrams that are not purely decorative have a luminosity contrast ratio of at least 5:1 when compared with their backgrounds." ---------------------------- Response from Working Group: ---------------------------- The topic of contrast in diagrams became so complicated and uncertain that diagrams were removed from the provision. It now only applies to text and images of text. RE: Decorative text, we do not require that decorative text need be high or low contrast. Just that there be sufficient contrast between non-decorative text and what is immediately around it. If the background of non-decorative text contains decorative text the contrast provision would apply. If not, we have no restrictions on it. ---------------------------------------------------------- Comment 17: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1162) 1.4.2 requires a mechanism to turn off "background audio that plays automatically, without requiring the user to turn off all audio". This is good except that "background audio" is not defined. Is it audio that is played at the same time as other audio, but is considered to be less important (i.e. background behind other audio)? Or Is it audio that is purely decorative and/or atmospheric, but not required for understanding or use of the web unit (regardless of whether other audio is playing)? Proposed Change: Define "background audio", or change "background audio" to either "audio" or "purely decorative audio". ---------------------------- Response from Working Group: ---------------------------- Good point. We have revised the success criterion 1.4.2 to read, "1.4.2 If any audio plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume which can be set independently of the system volume." ---------------------------------------------------------- Comment 18: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1163) 1.4.4 Note uses the phrase "four times (4x) quieter", but that seem a meaningless term. One can only talk about something being "four times louder" because loudness is measured relative to the absence of audible sound. "Four times quieter" would only make sense if noise A is compared with some other, even louder sound. Proposed Change: Change to read "Background sound that meets this requirement will be approximately one quarter as loud as the foreground audio content." ---------------------------- Response from Working Group: ---------------------------- We have updated the note to read, "Background sound that meets this requirement will be approximately one quarter as loud as the foreground speech content." ---------------------------------------------------------- Comment 19: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1164) 2.1.1 requires all functionality of the content to be operable in a non-time-dependent manner through a keyboard interface. However, many Web sessions eventually time out, and there is no practical way to design the server software to avoid this. Even when the Web content complies with criterion 2.2.1 and 2.2.6, which in many cases requires the user have some control over such time-outs, that does not make it comply with 2.1.1. Proposed Change: Define "non-time-dependent manner" as "method that does not require user action within any period shorter than ten minutes", or else add a Note to 2.1.1 explaining that server-based session time-outs of at least some minimum duration are not considered part of the content. ---------------------------- Response from Working Group: ---------------------------- Time-outs are covered under another success criterion. This refers to not requiring individual keys to be pressed or released under particular time contraints. To make this clear, we have rewritten the SC to 2.1.1 All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. ---------------------------------------------------------- Comment 20: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1165) 2.2.1 Is there a difference between a "time-out" and a "time limit"? The title refers to "time limits" but the wording of the SC uses "time-outs" in all but one instance. Proposed Change: Change "time-out" to "time limit" throughout 2.2.1. ---------------------------- Response from Working Group: ---------------------------- We have updated SC 2.2.1 to use the term "time limit" instead of "time-out". ---------------------------------------------------------- Comment 21: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1166) 2.2.1 applies to each time-out "that is a function of the content". Does that include time-outs that are applied by the server software, and of which the Web unit may have no knowledge (e.g. session timing out from inactivity)? Clarification is needed. The Understanding document addresses this but fails to clarify it, but it looks like server-based session time-outs would be non-conforming. Proposed Change: "Remove the phrase ""that is a function of the content"". Add clarification of server-based session time-outs to the Understanding document or the SC itself." ---------------------------- Response from Working Group: ---------------------------- The Success Criterion has been changed to clarify that it was intended that only time limits set by the content are in scope, and additional clarification has been added to the How to Meet document. ---------------------------------------------------------- Comment 22: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1167) Is it intended that ticket purchasing Web sites fail to conform because they only give the user two minutes to confirm a purchase before the seats are returned to the general pool and the user must start the process over again? If you don't want that fail, which of the exceptions would it fall under? (I don't see it falling under any of them as currently written.) If you do want it to fail, what would you recommend such sites do in order to become compliant, allow the user to extend the time limit up to a maximum number of times? This would be a good example to add. Proposed Change: Add to Understanding of Techniques an example of a ticket-purchasing Web site that allows the user two minutes to confirm purchase of selected seats, but warns the user when their time is almost out and allows the user to extend this time limit some number of times with a simple action such as clicking a "Extend time limit" button. ---------------------------- Response from Working Group: ---------------------------- Ticket purchasing Web sites in which tickets must be purchased quickly and cannot be held indefinitely would fall under the exception in the final bullet, in which the timeout is essential and cannot be extended without invalidating the activity. We have added an example to clarify this, and indicated that there could be ways to minimize the accessibility barrier provided. We also provide an example to indicate that tickets whose sale are not time sensitive do not fall under this exception. ---------------------------------------------------------- Comment 23: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1168) 2.2.2 requires content to not blink for more than three seconds or a method be available to stop all blinking in the Web unit or authored component. Many Web sites display GIF images that are provided by a third-party (e.g. advertisements, or user-contributed photos); are such sites required to ensure that none of those are animated GIFs, in case some blink? Is it sufficient for the authors to define a baseline that includes user agents that allow the user to stop blinking on the current Web unit (e.g. pressing ESC)? ---------------------------- Response from Working Group: ---------------------------- You ask two questions: 1)Yes, aggregators are responsible for the content they aggregate. If the aggregator wants to claim conformance at level AA, there must be no third party images integrated into the content which violate this success criterion. 2)It would be sufficient to use a technology for which user agents are available which allow the user to freeze the technology (as is the case of GIFs). This is the 2nd sufficient technique under SC 2.2.2. ---------------------------------------------------------- Comment 24: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1169) 2.2.3. requires that content can be paused by the user (barring certain exceptions). Pausing, as opposed to Stopping, implies there is UI to un-pause the content. Would it be acceptable to allow decorative content to be stopped, but not provide UI to resume it? The current wording would preclude that. ---------------------------- Response from Working Group: ---------------------------- The success criterion has been modified as you suggest to allow moving content that is pure decoration to simply be stopped without requiring a means to restart it. ---------------------------------------------------------- Comment 25: Source: http://www.w3.org/mid/00f101c69662$d121c310$0602a8c0@Lucky14 (Issue ID: LC-1170) 2.5.3 option 3 is that the user is able to review and confirm or correct information before submitting it. However, in almost all cases the user can pause after entering data, and review it before pressing ENTER or clicking SUBMIT, etc. I believe the intent of this option is that pressing ENTER or clicking SUBMIT should bring up a new Web unit that displays how the system interpreted what the user wrote (as opposed to what they thought they were writing). If so, shouldn't the wording make this clearer? Proposed Change: Change to read "The user is able to have the information they entered re-presented to them so they may review and confirm or correct it before final submission." ---------------------------- Response from Working Group: ---------------------------- The third bullet has been rewritten to make it clear that the user has the opportunity to review the results being submitted before confirming the transaction. The item now reads, "A mechanism is available for reviewing, confirming, and correcting information before finalizing the transaction." ---------------------------------------------------------- Comment 26: Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13 (Issue ID: LC-1171) 2.5 3 requires, for Double-A, that methods are provided to help avoid or undo errors, but only for a certain narrowly-defined set of interactions. I would recommend that these steps, or at least UNDO, be repeated as a level 3 success criterion, but applying to all interactions rather that just those listed in 2.5.3. Proposed Change: Add a new Level 3 success criteria: 2.5.5 For all user actions, at least one of the following is true: 1. Actions are reversible. 2. Actions are checked for input errors before going on to the next step in the process. 3. The user is able to have the information they entered re-presented to them so they may review and confirm or correct it before final submission. ---------------------------- Response from Working Group: ---------------------------- Thank you for your suggestion. The working group has determined that "all" user actions is too broad. For example, these techniques would not be appropriate for the action of logging out of a secure banking site or selecting a link that closes a window. However we've adopted it to a narrower focus of forms at Level AAA. Here is the language: 3.3.6: For forms that require the user to submit information, at least one of the following is true: 1. Reversible: Transactions are reversible. 2. Checked: Submitted data is checked for input errors before going on to the next step in the process. 3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the transaction. ---------------------------------------------------------- Comment 27: Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13 (Issue ID: LC-1172) 4.1.1 requires that Web content to be parsed unambiguously. Does this require the formal specifications be open, so that new user agents can parse the content? For example, suppose the baseline specifies just one Web browser, that implements rules for applying defaults to resolve any potential ambiguities in HTML that might be interpreted differently if another browser were used; is the HTML parsable unambiguously within the scope of the baseline? As another example, suppose a Web uses a proprietary data format that only a single plug-in can render; does it matter if it's parsable unambiguously if there is only one renderer? Proposed Change: Insert the phrase ", using publicly available specifications", to read "Web units or authored components can be parsed unambiguously, using publicly available specifications, and the relationships in the resulting data structure are also unambiguous. ---------------------------- Response from Working Group: ---------------------------- To make this requirement easier to understand, we have reworded SC 4.1.1 to clarify that it must be possible to parse content without the need for user agent repair. The revised SC reads as follows: 4.1.1 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. (Level A) 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. ---------------------------------------------------------- Comment 28: Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13 (Issue ID: LC-1173) 4.1.2 includes the phrase "available to user agents, including assistive technologies", but other criteria say "available to user agents" without the "including assistive technologies". The phrase is not strictly required since we define user agents as including assistive technologies; you may feel it's useful to re-emphasize that here, but if that's the case, wouldn't it also be warranted in those criteria that say "programmatically..." by adding "including assistive technology" to the definitions of programmatically set and programmatically determined? Proposed Change: Delete the phrase ", including assistive technologies", to read "For all user interface components, the name and role can be programmatically determined, values that can be set by the user can be programmatically set, and notification of changes to these items is available to user agents." ---------------------------- Response from Working Group: ---------------------------- Although the definition of user agent includes assistive technologies, the definition blurs the distinction between support for users with disabilities that is provided directly by the user agent and support that is provided by an external service that interacts with a user agent that does not provide that support directly. Within WCAG, we use assistive technology to refer to the latter sort of service. We call out support for assistive technology explicitly so that programmatically determinable information is available to assistive technology, and not just to the host user agent. In SC 4.1.2, it is a particularly important distinction for the notification of changes to user interface components. Information can be programmatically determined without requiring notification of changes. This would require constant polling of the content to notice changes. For many technologies, the host user agent is implementing the change, so it is automatically notified, but assistive technology needs explicit notification. ---------------------------------------------------------- Comment 29: Source: http://www.w3.org/mid/001501c59b26$aaec1bb0$6800a8c0@lucky13 (Issue ID: LC-1174) 4.2.2. says that if the user can enter content using the keyboard they must also be able to exit it using the keyboard, even if the content uses a non-baseline technology. This helps, but is not a complete solution, because it does not require that the keyboard method be discoverable by the user, especially if the user has a disability (e.g. a screen that cannot be read by a screen reader displays "text" telling the user they can exit by pressing F10, but the user who relies on the screen reader has know way of figuring that out). This is addressed in Techniques, but I fear that is inadequate because such documentation is so critical. Proposed Change: Change "If content can be entered using the keyboard, then the content can be exited using the keyboard." to read: "If content can be entered using the keyboard, then the content can be exited using the keyboard, and the method for doing so is described using technology in the baseline." ---------------------------- Response from Working Group: ---------------------------- Thank you for the suggestion. We have modified the success criterion to address the issue that you raised: 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."
Received on Thursday, 17 May 2007 23:34:53 UTC