- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:40:21 -0700
- To: "Lisa Seeman" <lisa@ubaccess.com>
- Cc: public-comments-WCAG20@w3.org
These responses are all to comments from the spreadsheet http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html ---------------------------------------------------------- Comment 1: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-606) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): Some widgets - such as a tree, the tab order will and should change when a component is expanded. It make no sense to say that that is not OK unless it is not predicable. As AT becomes used to these widgets, instruction will not be required Proposed Change: Changing the setting of any form control or field does not automatically cause a change of context (beyond moving to the next field in tab order or behavior for a progamaticly determinable widget type.), unless the authored unit contains instructions before the control that describe the behavior. ---------------------------- Response from Working Group: ---------------------------- We agree that what you cite should be allowed; it is already allowed under the current wording. Expanding the tree is a change of content, but not a change of context. The definition of "change of context" includes the note: "A change of content is not always a change of context. Small changes in content, such as an expanding outline or dynamic menu, do not change the context." Note that the clause "(beyond moving to the next field in tab order)" has been removed as unnecessary. ---------------------------------------------------------- Comment 2: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-607) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): I am concerned that level 1 SC will act against automatic help and combined with information hiding. For example when information is hidden unless you focus on the element in question, and then all the sub information about it is given. If you do not hide the information then the page becomes busy and you can not see what the main points are. If the user has a two strep process to access the information, then they may never receive it. As with many SC, they are OK if you read the definition, but if you just read the text it is misleading. Proposed Change: change the term "change of context" to "confusing change in context" the definition can remain the same ---------------------------- Response from Working Group: ---------------------------- The term "confusing" is subjective and would not be testable. Because keyboard users must often move focus through other controls to navigate to the control of interest, it is particularly important that just setting focus to a control does not have side effects. Although changes of content such as your example are not changes of context, and hence would not violate this success criterion. ---------------------------------------------------------- Comment 3: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-608) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): I am concerned that the requirement for real time synrcrization put a lot of extra work on authors who would like to provide short animations or clips that help people with learning disabilities fulfill a task. On the whole, a lot of multi media, especially in education, is good for many learning disabilities, and these requirements may act as a step backwards for learning disabilities. Proposed Change: Make an exception in 1.2 for any content provides extra help visual for tasks and information that has been described in text else wear. ---------------------------- Response from Working Group: ---------------------------- We have added an exception to SC 1.2.1 so that captions are not needed when the multimedia is presenting information that is already available as text: 1.2.1 Captions: Captions are provided for prerecorded multimedia except for multimedia alternatives to text that are clearly labeled as such. We have also updated the intent section for this criterion to reflect this change. ---------------------------------------------------------- Comment 4: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-609) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): To my mind the most important aspect if predictability is exposing to the user agent what each thing is. That way the interface can be tailored to the user's access strategy. If XHTML 2 roles are known - what is main and what is secondary navigation, then the order becomes less important. Proposed Change: add success criteria ---------------------------- Response from Working Group: ---------------------------- This requirement is covered in SC 4.1.2 "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, including assistive technologies" and in SC 1.3.1 "Information and relationships conveyed through presentation can be determined programmatically, and notification of changes to these is available to user agents, including assistive technologies." While additional roles will assist with navigation, the working group does not feel the need to add an explicit navigation-related success criterion requiring these roles, since they are already covered by SC 1.3.1. The current success criteria do not preclude the use of navigational roles to improve the accessibility, and some of the techniques for these success criteria depend upon the availability of reliable role information. ---------------------------------------------------------- Comment 5: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-610) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): Terms in the document often seem to mean something a bit different, until you read the definitions. As WCAG is often quoted the terms themselves should be as close to clear language as the can be without viewing the definitions. Proposed Change: change the term "programticly determined", to "supported by Assistive technology". ---------------------------- Response from Working Group: ---------------------------- We have struggled to make the concept of "programmatically determined" and other terms used in the document as clear as possible. Unfortunately, "supported by assistive technology" captures only part of the meaning of programmatically determined. The author must also have provided the data in a form that makes information and relationships clear by using appropriate markup within the technology. Note that the definition of programmatically determined has been amended to say "including assistive technology." ---------------------------------------------------------- Comment 6: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-612) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): Adaptive interfaces are a good thing. sometimes change is because we know more about what the user likes Proposed Change: change the wording ...occur in the same relative order each time they are repeated, unless a change is initiated by the user or may benifit the user ---------------------------- Response from Working Group: ---------------------------- This success criterion applies to the logical order and default presentation of the content. This success criterion does not prohibit choices in adaptive interfaces; enabling adaptive interfaces and alternate presentations is a goal of WCAG2. However, the user still needs to initiate the change in order, even if the change is initiated by global actions such as selecting preferences in a user agent or using a user agent with adaptive behavior. We have added this explanation to the Intent Section of the How To Meet document. ---------------------------------------------------------- Comment 7: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-613) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): To get to CR (candidate recommendation we believe two things are required. 1, Concrete checkpoints or list of requirements 2, Tests that completion of the minimum requirements of success criteria at each level will make sites progressively usable for people with disabilities listed in the overview. Proposed Change: Create a list of "what to do" checkpoint ---------------------------- Response from Working Group: ---------------------------- We have released the Quick Reference document (http://www.w3.org/WAI/WCAG20/quickref/) which provides a compact list of the success criteria (the checklist items for WCAG 2.0) with the techniques that are sufficient listed directly beneath them. Each technique has a test that can be used to confirm implementation. If you mean that we need a checklist for getting to CR, there is a list of things that must be met in W3C Process Document. With regard to your second point, this type of testing is beyond what can be done in CR. This would be an interesting research project but would require considerable funding. ---------------------------------------------------------- Comment 8: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-614) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): Level 3 success criteria: 1. Achieve additional accessibility enhancements. 2. Can not necessarily be applied to all Web content. I object to definition. Because many criteria are level 3 only because they are considered too hard to do on all web content does not mean that level 1 and two achieve minimal and enhanced accessibility. Level 3 is also minimal accessibility Proposed Change: change of wording Level 3 success criteria: 1. Achieve minimal accessibility, or, if the Success criteria can be applied to all Web content, achieves additional accessibility enhancements. 2. Can not necessarily be applied to all Web content. ---------------------------- Response from Working Group: ---------------------------- We have completely rewritten this section of the guidelines (see http://www.w3.org/TR/2007/WD-WCAG20-20070517/#overview-levels ): The word "levels" does not mean that some success criteria are more important than others. Each success criterion in WCAG 2.0 is essential to some users, and the levels build upon each other. However, even content that conforms at AAA (triple-A) may not be fully accessible to every person with a disability. *In general, Level A success criteria achieve accessibility by supporting assistive technology while putting the fewest possible limits on presentation. Thus people with a wide range of disabilities using a wide range of assistive technologies, from voice input and eye-tracking devices to screen readers and screen magnifiers, are able to access content in different ways. In other words, Level A success criteria support the ability of both mainstream and specialized user agents to adapt content to formats that meet their users' needs. *The success criteria in Level AA provide additional support for assistive technology. At the same time, they also support direct access to content by the many people who use conventional user agents without assistive technology. In general, Level AA success criteria place more limits on visual presentation and other aspects of content than the success criteria in Level A. *Level AAA success criteria increase both direct access and access through assistive technology. They place tighter limits on both presentation and content. ---------------------------------------------------------- Comment 9: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-615) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): The claim in http://www.w3.org/TR/WCAG20/Overview.html learning difficulties, cognitive limitations, However the checkpoints towards understandability even at level 3 addresses only secondary education level – in other word usable for mainstream people without these disabilities. The basic mechanism for simplifications have not been included, or use of symbols or conversion to symbols. Also left out are use for controlled languages The result: I read a lot of complex specification. I am even writing W3C specifications, but WXAG is the only on that I can not follow though because of my disability. I can understand the concepts, but the presentation requires remembering what technique 3.1.3 was for, and then (if I forgot what 3.2.3 stood for, going back to the original guidelines finding it, hopefully not confusing it with 1..3.2 etc – why because WCAG are following there own specifications, so I, as a person with a disability, can not use their material. to say "this document contains principles, guidelines, and success criteria that define and explain the requirements for making Web-based information and applications accessible" and to include learning difficulties, cognitive limitations is an insult to anyone with learning memory or cognitive impairments. there are many clear sets of guidelines that do that. WCAG is not one of them. Proposed Change: Practical proposal – state clearly that learning difficulties, cognitive limitations are not fully addressed beyond a very limited way. Then work on a extended guideline, be it optional and untestable, success criteria that does the job. ---------------------------- Response from Working Group: ---------------------------- We have added language to the Introduction, the Conformance section, and the Quick Reference to highlight the fact that WCAG 2 only addresses some of the needs of people with cognitive, learning, and language disabilities, and to call out the need for more research in this area. WAI is exploring ways in which to support and encourage work in this important area. We have added some best practices for cognitive, learning, and language disabilities as advisory techniques, and we have proposed 3 new success criteria in this area. ---------------------------------------------------------- Comment 10: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-616) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform3ch.html Comment (including rationale for any proposed change): 1. Identifying changes in natural languages USING a technology-specific technique listed below AND Identifying text direction of passages and phrases USING a technology-specific technique listed below (for a technology in your baseline) The example is an odd one because always, when changing direction, you are changing characters and there for it is, by definition programticly determined More over bILI languages change direction all the times whenever numbers are used. Are you really expecting each number to be in it's own span? Why not follow the standard BILI algorithms ---------------------------- Response from Working Group: ---------------------------- Based on comments from the Internationalization Working Group, we have determined that text direction is not an accessibility issue unless it affects the meaningful sequence of text. SC 3.1.2 no longer requires that the direction of text be identified.
Received on Thursday, 17 May 2007 23:40:43 UTC