- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:27:11 -0700
- To: "Al Gilman" <Alfred.S.Gilman@ieee.org>
- Cc: public-comments-WCAG20@w3.org
Comment 31: Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5] (Issue ID: LC-1200) "content is perceivable" is an oxymoron. The two are not comparable. The rendering is perceivable. In the rendering, the content must be recognizable. ---------------------------- Response from Working Group: ---------------------------- Principles are not a technical provisions, but something to provide a gestalt. We have changed them to a certain extent but we want them to be short slogans that are easily remembered and understood as overarching principles. They now read: 1. Perceivable - Information and user interface must be perceivable by the user. 2. Operable - User interface components must be operable by the user. 3. Understandable - Information and operation of user interface must be understandable by the user. 4. Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. ---------------------------------------------------------- Comment 32: Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5] (Issue ID: LC-1201) It doesn't work until the content is re-united with an adapted presentation. Proposed Change: change to: Ensure that presentation can be adapted while preserving content. Alternate language: Enable personalization of presentation. ---------------------------- Response from Working Group: ---------------------------- Guideline 1.3 has been reworded to reflect adaptation of presentation. Separation of content and presentation would be a technique for this. ---------------------------------------------------------- Comment 33: Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5] (Issue ID: LC-1202) Requiring that the other way of showing the color-signaled information is visual is a UI requirement. It is not a content requirement. This requirement is inappropriate for a claim that includes SALT in its baseline such that the default presentation would speak the information as well as show it with color. Compare with UAAG 2.3. Sometimes you should not try to replicate the richness of the color coding in other, more limited property spaces, but rather signal that there is further information and expand on the further information on user interactive request. Compare also to the 'minimized' treatment of notes in a DAISY player. Here the presence of a note is evident, the content of the note is available but on an 'ask for' basis. 24 bits per pixel of color-coded information is just too much information to assume that other visual effects can capture it all. Proposed Change: User Interface requirement: strike the word 'visually' to leave "is also evident, or is available and the availability of more information is evident" Content requirement: The default prsentation afforded without user intervention satisfies the above requirement. [alternate language: .. is visually evident ... in the author-designed visual presentation of the content] Content requirement: The connotations of color and other presentation-properties constitute non-text information and must (per 1.1.1) be afforded text explanations that are associated with the items bearing these presentation effects (and connotations), associated by an association that can be programmatically determined. ---------------------------- Response from Working Group: ---------------------------- The group thinks that situations where the density of the color would affect the information in such a way that it is too subtle or complicated to be visually rendered in another way, are extremely rare. UAAG 2.3 applies to conditional content, and is not equivalent to necessary information that a color blind person can't access. The DAISY player example of minimizing notes is a different issue because they are not equivalents to content. They are enhanced information, so it makes sense that people should take extra steps to access that information. The group does not think color blind people should be required to go elsewhere to get basic information in circumstances such as those covered in this success criteria. Color, as it applies to this success criteria, is often text based information, and therefore would not be covered under SC 1.1.1. ---------------------------------------------------------- Comment 34: Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5] (Issue ID: LC-1203) "content is perceiveable" is an oxymoron; the content may be unrecognizable if the features of the rendered presentation are not perceivable, but perceivable features are not an independent principle, they are just a possible failure mode for the success which is understanding what was being represented in the rendered content. Understanding is an independent requirement, perception is an instrumentality. Compare with how people can frequently read text where all but the first and last letters of each word are obscured beyond recognition. This rendered content would flunk a 'perceivable' test but pass a 'recognizable' test thanks to the inherent redundancy of natural language. The whitespace between glyphs is either perceivable or not perceivable. The functional requirement if the glyphs are spelling some natural langugage is that the user be able to recognize the natural language represented by the glyphs in the rendered content. The term 'recognizable' is a significantly better fit to the requirement, here, as opposed to 'perceivable. Proposed Change: Change to [words to the effect that] "information is recognizable in the rendered content at the user interface -- a) [best] as configured to be presented by the author and server b) [good] as presented in a delivery context where the user employs readily-achievable adjustments to the look and feel or c) [OK when that's all that works] c) as available in a readily discovered and followed alternate path through the content." ---------------------------- Response from Working Group: ---------------------------- Principles are not a technical provisions, but something to provide a gestalt. We have changed them to a certain extent but we want them to be short slogans that are easily remembered and understood as overarching principles. They now read: 1. Perceivable - Information and user interface must be perceivable by the user. 2. Operable - User interface components must be operable by the user. 3. Understandable - Information and operation of user interface must be understandable by the user. 4. Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. ---------------------------------------------------------- Comment 35: Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5] (Issue ID: LC-1204) The principle is that "what one can do, others can do." Interactive objects are an instrumentality, an intermediate level of representation. The content can succeed by affording equivalent facilitation for widgets through menus or other widgets or voice command. Proposed Change: There are two principles here: 1) What one can do, others (PWDs) can do. [This is more likely the section head for device-independent interaction etc.] 2) Afford remediation [restore a usable look-and-feel] with as little deformation of the look-and-feel as possible. [This is probably a separate, cross-cutting section explaining why color coding should be _visually evident_ where readily achieved, etc.] ---------------------------- Response from Working Group: ---------------------------- We believe that those two principles are too abstract. We believe that the current structure is more salient. ---------------------------------------------------------- Comment 36: Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5] (Issue ID: LC-1205) Seizures are actual harm to the user independent of whether there is any value in the Web content there to be accessed. True, the seizures can prevent access to value in the content but before one even gets there there is harm done. Proposed Change: Break out a separate "first, do no harm" principle and put 2.3 under it. Introduce no impediments to people citing or implementing this provision as severable from any of the rest. ---------------------------- Response from Working Group: ---------------------------- This makes sense, but we don't want to have a principle with only one provision under it. We have, however, added the following conformance criterion: Non-Interference: Use of any technologies that are not accessibility-supported content technologies does not interfere with use of the accessibility-supported content technologies used to conform to these guidelines. Specifically, content meets the following criteria even if the content uses non-accessibility-supported technologies: 1. No Keyboard Trap: 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. 2. Flash Threshold: To minimize the risk of seizures due to photosensitivity, content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds (see Success Criterion 2.3.1). 3. Non support: The content continues to meet the conformance requirements when the (non accessibility-supported) technology is turned on, turned off, or is not supported by a user agent. ---------------------------------------------------------- Comment 37: Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5] (Issue ID: LC-1206) Good; but there are a few things mis-filed Proposed Change: move 3.2.5 to a "what user can do" section containing most of the Principle 2 material. Move Guideline 2.4 to a "what the user needs to be able to understand" section containing most of what is presently Principle 3 material. ---------------------------- Response from Working Group: ---------------------------- SC 3.2.5 isn't a problem with inability to operate, but a problem with disorientation. Regarding Guideline 2.4, these criteria do fit in both categories. However, the working group feels these criterion have more to do with operation than they do with understanding. ---------------------------------------------------------- Comment 38: Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5] (Issue ID: LC-1207) Compatibility with the future is a guaranteed "cannot complete a valid Candidate Recommendation" clause. PF definitely sympathizes with your desire to have the content create a responsible document object model regardless of the AT uptake of the information at the moment. We want that to. But the way to achieve this is to have a concrete proposition as to the information that has to be available in machinable form; not to say "anything the user may infer from the rendered content must be encoded in a machine-recognizable notation." That isn't going to work. The way to success is, for example, take a label. The requirement here is indicated by the dialog: Q1: Can the user do something, here? A1: Yes. Q2: what can they do? A2: Q3: what in the user experience tells them that? A3: This . If the association of A3 as label for the action is machine recognizable, and the user should be able to recognize A2 from A3, then we are done. That is the general pattern to be replicated across the essential information to answer questions of "Where am I?" "What is _there_?" "What can I do?" .. at a fine enough grain so that the answers are always in the context that the use can recall or associate with their current place-in-browse (e.g. focussed object or reading cursor). Proposed Change: Build on contribution expected from IBM as to how to reword 4.1. We need to connect several things: information required for an 'informed' user browse; machinable notations so UA can map to API the AT understands; format specs that afford the ability to have a shared understanding among author, author-automation, user-automation, and user. Spell out information requirements in Principle 3 -- what the user needs to be able to understand (including about what they can do). ---------------------------- Response from Working Group: ---------------------------- Thank you for your comment. We have removed the phrase to read: "The goal of this approach makes it possible to apply WCAG 2.0 to a variety of situations and technologies." We have also added a section to Understanding WCAG 2.0 titled, "Understanding the Four Principles of Accessibility." which includes additional explanation about the principles. ---------------------------------------------------------- Comment 39: Source: http://www.w3.org/mid/p06110403c0bf326d6713@[10.0.1.5] (Issue ID: LC-1208) equivalent facilitation does not only apply to future technologies, or only to technologies outside your baseline. This is a principle that applies across the board. Compare with comments on "one strike and you're out" roll-up in the comments on the conformance scheme. Proposed Change: re-write the document and conformance scheme so that it is obvious that the remedy for a potential problem may come at a different level of aggregation from where the potential problem was noticed. For example, a CAPTCHA in the login process may be worked around by a totally different login process. In other words the failure of access is local to the image but the affordance of accommodation or relief is through equivalence at the task, not the image, level. For another example, a diagram in SVG may afford the user a navigable structure of focusable elements. If these represent the notional objects in the scene, and they are suitably titled and otherwise annotated with properties and relationships, the text equvalent for the image may be provided at a lower level of aggregation by providing text associated with the parts of the image. So the relief may be at a higher or lower level of aggregation from the perception of a possible problem (recognition of a match to the selector or applicability-condition I would call the "left-hand-side" of a rule e.g. success criterion). ---------------------------- Response from Working Group: ---------------------------- Currently there is no requirement that the work-around be at the same level of aggregation on a web page, as long as it is on the same page (see definition of web page) so equivalent facilitation is permissible at a different layer of aggregation (as long as it is at the same URI). For instance, in the case of the CAPTCHA example you gave, the different login process would conform as long as it could be reached from where the CAPTCHA is situated.
Received on Thursday, 17 May 2007 23:27:30 UTC