- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Sat, 3 Nov 2007 21:33:16 -0700
- To: "Greg Lowney" <gcl-0039@access-research.org>
- Cc: public-comments-WCAG20@w3.org
Comment 13: What platforms must be supported? Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2141) ---------------------------- Original Comment: ---------------------------- 1. The Conformance section does not address the question of which platforms need to be supported. If something only runs on one platform, what determines if it is accessible? What if the plug-in required for viewing it does not support Linux? --------------------------------------------- Response from Working Group: --------------------------------------------- We do not have any requirements for platforms per se, but the description of accessibility support for a technology should note which platforms the technology has AT support on. This is described in the section "Understanding Accessibility Support" in "Understanding Conformance". ---------------------------------------------------------- Comment 14: machine-readable Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2142) ---------------------------- Original Comment: ---------------------------- 2. Conformance, Optional components of a conformance claim, uses the term "machine-readable metadata", which occurs nowhere else in the document. Is the intention that this metadata be in a standardized form, or merely that it can be accessed as text without the use of optical character recognition? Should it be added to the glossary? --------------------------------------------- Response from Working Group: --------------------------------------------- Yes, it is the intent that it be in standard form but we are not specifying a particular standard. This is described in the "Understanding Conformance" document as follows: "The most useful way of attaching conformance claims to content would be to do so in standard machine readable form. When this practice is widespread, search tools or special user agents will be able to make use of this information to find and provide content that is more accessible or so the user agents can adjust the content. There are a number of metadata based options under development for making claims, and authors and tool developers are encouraged to support them. In addition, metadata can be used to report conformance to individual success criteria once Level A conformance has been achieved. There are also programmatic reporting formats such as Evaluation and Report Language (EARL) that are being developed that could provide machine readable formats for detailed conformance information. As the reporting formats are formalized and support for them develops the will be documented here." ---------------------------------------------------------- Comment 15: Duplicate handle Source: http://http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2143) ---------------------------- Original Comment: ---------------------------- 3. 2.2.4 has the title "Timing:" which is also the title of 2.1.1. In all other cases, each title is unique. I suggest changing the title of 2.2.4 to "Timing (Enhanced):" --------------------------------------------- Response from Working Group: --------------------------------------------- Thanks for catching this duplication. We changed the handles for SC 2.2.1 and 2.2.3 so they are not identical. ---------------------------------------------------------- Comment 16: Use a variety of screen readers in Conformance Claim examples Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2144) ---------------------------- Original Comment: ---------------------------- 4. I recommend Examples of Conformance Claims in the Understanding document include references to more than one screen reader. Currently, Jaws is the only one named, and it is named five times. --------------------------------------------- Response from Working Group: --------------------------------------------- Thank you for pointing this out. We have made the names of specific products non-specific. ---------------------------------------------------------- Comment 17: moving fomer SC into conformance Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2145) ---------------------------- Original Comment: ---------------------------- 5. I believe I understand the rationale for moving several (former) success criteria into the Conformance section, but I am worried about two things. First, they are no longer easily referenced; can you call them something like "CR6.1, No Keyboard Trap"? Second, it seems like they are likely to be overlooked when someone is reading what they consider to be the key sections, or a summary of the guidelines. I would not be surprised to see the H1 section titled "WCAG 2.0 Guidelines" being extracted or considered the key portion, and it used to be so, but now the H2 section titled "Conformance Requirements" is just as important for actual content developers, not just managers. Some specific factors that could lead the latter to be overlooked are (a) it's only H2 instead of H1, (b) it is surrounded by other H2 sections that look much less like lists of guidelines and more like paragraphs of text, and (c) the sections around it are more applicable to managers than to individual designers and authors. I don't have a good suggestion for mitigating this problem, but perhaps the working group can think of something. --------------------------------------------- Response from Working Group: --------------------------------------------- We have moved the conformance requirements to the front of the section. ---------------------------------------------------------- Comment 18: autoadvance on focus Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2146) ---------------------------- Original Comment: ---------------------------- 6. 3.2.2 "On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component." None of the Understanding or Techniques addresses the common situation where several form fields are used to enter the fixed-length segments of multi-part value, such as a serial, phone, or social security number. In those cases it is common for the focus to automatically move to the next field when the correct number of characters have been entered. While this is common and a convenience to many users, it would violate this success criterion and should be addressed specifically. --------------------------------------------- Response from Working Group: --------------------------------------------- We think these are examples of advancing the focus when the setting of the user interface component has been changed, e.g., characters have been typed into the fixed-length text field. While this sort of situation is becoming more common, we believe it is non-standard behavior for user interface controls that can cause confusion for users. In order to avoid violating SC 3.2.2, the user should be advised of this behavior. It is then predicable and would not violate this success criterion. ---------------------------------------------------------- Comment 19: better handle for bullet 1 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2147) ---------------------------- Original Comment: ---------------------------- 7. 1.1.1 bullet 1, "Controls-Media", could be renamed to "Controls, Input" to be more consistent with the other bullets (e.g. "Media, Test, Sensory" and "Decoration, Formatting, Invisible". --------------------------------------------- Response from Working Group: --------------------------------------------- Done. Thank you. ---------------------------------------------------------- Comment 20: make handle consistent with SC Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2148) ---------------------------- Original Comment: ---------------------------- 8. 1.3.3. Minor, editorial only, but you might consider changing the either the title ("Size, Shape, Location") or the text ("shape, size, visual location, or orientation") so the two use the same order. --------------------------------------------- Response from Working Group: --------------------------------------------- In response to another comment we received, we changed the handle to 'Sensory Characteristics', which eliminates the concern you raised. ---------------------------------------------------------- Comment 21: suggested new SC Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2149) ---------------------------- Original Comment: ---------------------------- 10. I consider it unfortunate that the Keyboard section does not contain a AA or AAA criterion addressing the benefit of having a keyboard interface that does not require reference to spatial arrangement of items on the visual display. For example, "Non-relative: All functionality of the content is operable through a keyboard interface without requiring timings for individual keystrokes or reference to the spatial arrangement of content or controls on the visual display." --------------------------------------------- Response from Working Group: --------------------------------------------- The issue you are concerned with is covered by 2.1.3 Keyboard (No Exception) and by 1.3.3 Sensory Characteristics. ---------------------------------------------------------- Comment 22: Change level to AA or AAA Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2150) ---------------------------- Original Comment: ---------------------------- 11. 2.4.4 Link Purpose (Context): I don't consider this a Single-A criterion, as this level of information is often not available to most users. I think that in the vast majority of cases, it is merely implied rather than in any way made explicit. I would be fine with it being demoted to either Double-A or Triple-A. --------------------------------------------- Response from Working Group: --------------------------------------------- Thank you. We have revised SC 2.4.4 to better reflect current support of assistive technology. Over time we expect that the assistive technology support will also improve for the other options. While the working group encourages authors to make link text as descriptive as possible out of context, we do not feel that this success criterion can be satisfied for all Web pages. For Example: - a page has book titles followed by PDF, HTML, DOC. - Article name (long) followed by a sentence and the link "more" - GOOGLE search where each entry has text plus the following links [translate this page] HTML and [CACHED] and [SIMILAR PAGES] - toolbar with menus with an arrow icon - the link says "open". Having full links makes the page very cluttered, harder cognitively to find things when the same long (sometimes multi-line) text is repeated with one word different, and is very long to listen to for those not adept at auditory skipping (or where unique information is back end loaded). These issues were considered carefully for a long time, the working group feels that having 2.4.4 at Level A and this issue addressed at Level AAA strikes the right balance. While user agent and assistive technology support for finding the link context is poorer than we would like, we have checked that there is at least one case of support for each of the types of link context we have listed as sufficient techniques. So a user who has tabbed to a link can ask for those pieces of context without leaving the link. We hope that if authors satisfy SC 2.4.4 and make link context programmatically determinable, user agent developers will find a way to let users access the context when needed, such as when the link list is created. ---------------------------------------------------------- Comment 23: use of title attribute Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2151) ---------------------------- Original Comment: ---------------------------- 12. 2.4.4 Link Purpose (Context): Note that in addition to link text and "programmatically determined link context" the Title attribute is often used to provide information about the purpose of a link. This is done in the WCAG 2.0 document itself, where the title attribute of link to a definition is prefixed with "definition: ", and many user agents provide a UI to present this title to the user. --------------------------------------------- Response from Working Group: --------------------------------------------- The title attribute is considered programmatically determined link context, and its use is listed as a sufficient technique for this success criterion. (See H33: Supplementing link text with the title attribute) ---------------------------------------------------------- Comment 24: programmatically determinable Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2152) ---------------------------- Original Comment: ---------------------------- 13. 2.4.4 and Definition of "programmatically determined link context", I believe this would more properly be described as "programmatically DETERMINABLE link context", as the current wording literally means link text that is assigned programmatically. --------------------------------------------- Response from Working Group: --------------------------------------------- A good observation. We have changed SC 2.4.4 as you suggested. It now reads: 2.4.4 Link Purpose (In Context): The purpose of each link can be determined from the link text alone, or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general. ---------------------------------------------------------- Comment 25: WCAG doesn't meet 2.4.8 Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2153) ---------------------------- Original Comment: ---------------------------- 14. 2.4.8 Link Purpose (Link Text): Note that I don't think even the WCAG document itself meets this criterion. --------------------------------------------- Response from Working Group: --------------------------------------------- We agree, it is not always possible for all Web pages to satisfy all Level AAA success criteria. Content that includes links to definitions (like in the WCAG) is a good example of why this SC is included at level AAA. ---------------------------------------------------------- Comment 26: Only change of context prohibited on focus Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2154) ---------------------------- Original Comment: ---------------------------- 15. 3.2.1 On Focus: This prevents an unexpected "change of context" when any component receives focus, but no criterion currently restricts components from making other persistent changes, such as changing the state of a check box, simply because it received focus. This would be analogous to the case of a radio button becoming selected merely because the user moved focus to it, an error which we have seen in some desktop applications. I would have liked to see added "....or any effect that will persist after the component has lost focus". If this cannot be added to Single-A at this point, could it be added as Double-A or Triple-A? --------------------------------------------- Response from Working Group: --------------------------------------------- Whether setting focus on a radio button will change the state of that control will depend on the user agent. In fact, the behavior you describe is the expected behavior for radio buttons for screen readers in some reading modes. Therefore, we feel it would be confusing to introduce a requirement like this. We agree, however, that such changes on focus should generally be avoided, and we have added an advisory technique "Not causing persistent changes of state or value when a component receives focus, or providing an alternate means to reset any changes". ---------------------------------------------------------- Comment 27: Description of method must be encountered before content Source: http://lists.w3.org/Archives/Public/public-comments-wcag20/2007Jun/0300.html (Issue ID: 2155) ---------------------------- Original Comment: ---------------------------- 16. "Content that is not accessibility-supported contains a link to information about how to move focus back to the accessibility-supported content via the keyboard." This fails to address the part of the Conformance Requirement that says "the method for doing so is described BEFORE the content is encountered". --------------------------------------------- Response from Working Group: --------------------------------------------- We have revised the example as follows: A page that includes content that is not accessibility-supported contains instructions about how to move focus back to the accessibility-supported content via the keyboard. The instructions precede the non accessibility-supported content.
Received on Sunday, 4 November 2007 04:33:38 UTC