- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:40:14 -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/wcagform_ch2_.html ---------------------------------------------------------- Comment 1: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-624) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for proposed change): Interfaces become inoperable when one of the following brake: 1. Each element or widget is marked with full and corrected semantics that fully describes it's behavior Note this is more then information and structure can be separated from presentation .This includes creating enabled javascripted widgets that the Assistive Technology does not know what it is, what states are supported and how it maps to the operating system API. If non exists (like a tree item that can expand to a sub tree when you click on it) Then you may need to add a technology, such as xforms, XHTML 2 Roles 2. The relationships between elements and groups are known. Again, this is more then I see supported by navigation Success criteria. What form element controls what AJAX operated section is a good example of a relationship 3. States, properties, and relationships are valid for each elements behavior and are accessible via the DOM. For example if clicking on a tree item makes it expand or collapses, then it's state (such as expanded) needs to be accessible via the Document Object module Via an attribute that can be understood by assistive technology.. 4. There is an element having the correct input focus. This is different to just being keyboard navigatable Proposed Change: Add success criteria at level 1 along the lines of: 1, The supported behavior of each element and widget can be programaticaly determined. 2, The relationships between elements and groups of elements can be programaticaly determined. 3, States, properties, and relationships are valid for each elements behavior can be programaticaly determined. 4, There is consistently an element having the correct input focus. ---------------------------- Response from Working Group: ---------------------------- The working group believes that your concerns for additional level A success criteria have already been met with existing criteria. Success criterion 4.1.2 covers the supported behavior of each element and the states, properties and relationships of elements and requires that they be programmatically determinable. The relationships between elements are covered by success criterion 1.3.1. Both of these are level A success criterion. For example, the pressed state of buttons is not currently exposed by user agents to assistive technology. In addition, the lack of states and relationships does not block accessibility today and the current success criteria do not block future technology which provides additional role, state, and relationship information. We also do not believe that there should be a requirement for always maintaining an element with input focus. For the bulk of content the current focus mechanism is sufficient and allows page scrolling with arrows and change of focus into the user agent address bar with no interaction from the Web content author. ---------------------------------------------------------- Comment 2: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-625) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for proposed change): Web units have titles, what is the advantage if the titles are not descriptive? Proposed Change: change to Web units have descriptive titles ---------------------------- Response from Working Group: ---------------------------- We have changed SC 2.4.3 to "Web pages have descriptive titles" and have also reflected this change in success criterion 2.4.5 and the support documents for both success criteria. ---------------------------------------------------------- Comment 3: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-626) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for proposed change): surely this only helps if titles are unique -any objection to unique should not apply at level 3 Proposed Change: change to Web units have descriptive and unique titles ---------------------------- Response from Working Group: ---------------------------- We have changed SC 2.4.3 to "Web pages have descriptive titles" and have also reflected this change in success criterion 2.4.5 and the support documents for both success criteria. The success criterion does not require that titles be unique because the working group is concerned that requiring uniqueness will lead to titles that are not as descriptive and usable. It may be very difficult to create titles that are descriptive, unique, and reasonably short. For example, a Web page that generates titles dynamically based on its content might need to include part of the dynamic content in the title to ensure that it was unique. We are also concerned that authors may make titles unique mechanically, such as by including a unique number in the title that is unrelated to the content. For these reasons, although we encourage unique titles in the techniques for this success criterion, we are not including uniqueness in the success criterion itself. ---------------------------------------------------------- Comment 4: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-627) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for any proposed change): sections of content need titles to be able to navigate through a page. This is particularly true of many AJAX sites that have multiple regions. The regions of a page can change at different rates due to either user actions or asyncrones updates. The user may need to toggle between form controls to results, and updates. Even in simpler content knowing that a table has a navigation function is hugely usefully even when accessibility is not completely broken. Proposed Change: Add level one success criteria Blocks of content that become updated should be uniquely titled or it's role can be programaticaly determined When multiple blocks of content in a web unit have the same role they should be uniquely titles Blocks of content that perform a common task should be titles or its role can be programaticaly determined success criteria 2.4.1 is no longer needed ---------------------------- Response from Working Group: ---------------------------- The WCAG WG did not create a success criterion specific to live regions. However SC 4.1.2 was modified to require the general case that roles, states, properties, and values be programmatically determined. In addition, the ability to navigate easily to such regions is an important point and related to other needs as well. Therefore, we created a new Level AAA success criterion in GL 2.4 "2.4.9 Section Headings: Where content is organized into sections, the sections are indicated with headings." Various ways of conforming to this success criterion would exist, including the suggestion to provide headers for live regions as well as any other meaningful section of content. The technique on 'live regions' is advisory at this time because the technology has not been released yet. ---------------------------------------------------------- Comment 5: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-628) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for any proposed change): 2.4.6 When a Web unit or authored component is navigated sequentially, components receive focus in an order that follows relationships and sequences in the content. [How to meet 2.4.6] this should be level 1 as it often completely brakes the user interface Proposed Change: move SC 2.4.6 to level 1 ---------------------------- Response from Working Group: ---------------------------- Because assistive technology cannot provide access to rerendered content if this success criterion is not satisfied, it has been moved to level A. ---------------------------------------------------------- Comment 6: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-629) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for any proposed change): In the roles specification we now have a range widget, which means you can state, in a programaticaly determined way what the max and min values are. That means that AT can give users the message any way they want - including text, if they want. Surly this is better then requiring text we also have in the adaptable states and properties module a required attribute, (for situation B in the "how to understand this checkpoint) Note this is all part of the WAI, and screen readers are working to support it today... Proposed Change: change 2.5.1 to: If an input error is detected, the nature of the error can be programaticaly determined or identified and described to the user in text. ---------------------------- Response from Working Group: ---------------------------- This success criterion does not prevent the use of programmatic information which can be used by AT or the user agent to identify and provide error information. There must be some mechanism to provide the error information to the user with all technologies in use today and the requirement for text guarantees that. Even when provided by the AT or user agent rather than the content author, the information can still be conveyed in some form of text to meet this requirement. Thus, we don't see the requirement for text as being too restrictive. ---------------------------------------------------------- Comment 7: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-630) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for any proposed change): 2.5.2 If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user. With things like role attribute you can assign a functional role to an element, and other important information such as allowable range. That means that the assistive technology can themselves perform validation. Makes it all a user agent thing... Proposed Change: 2.5.2 If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the suggestions are provided to the user or can be progmaticly determined ---------------------------- Response from Working Group: ---------------------------- The current success criterion does not prevent use of Dynamic Web Content Accessibility, XForms or other technologies to provide information that will allow user agents and assistive technologies to provide suggestions for error correction. We do not feel we need to specifically add "programmatically determined" to the success criterion, but such technology-specific techniques could be added as sufficient as user-agent support for them improves. If role and validation information is programmatically provided in the markup for a technology and testing demonstrates that suggestions for error correction are provided to the user via the user agent or assistive technology, this success criterion has been satisfied. The technology-specific techniques should be provided for such technologies. We have provided some advisory techniques for the use of WAI-ARIA and will promote them and will promote them as they qualify as accessibility supported in some environments. ---------------------------------------------------------- Comment 8: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-631) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for any proposed change): With things like role attribute you can assign a functional role to an element, and other important information such as allowable range. That means that the assistive technology can themselves perform validation. We should also work on identifying critical tasks. Hence one of the list should be (for future proofing) the role of all information and it's critical nature can be progmaticly determined Proposed Change: 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 review and confirm or correct information before submitting it. 4. The role of each control and it's critical nature can be progmaticly determined. ---------------------------- Response from Working Group: ---------------------------- This success criterion is addressing the problem of users making irreversible mistakes in the otherwise valid values provided or actions taken. Indicating that a control is critical is not sufficient to satisfy this success criterion. The user must still be given the opportunity to avoid unrecoverable errors. ---------------------------------------------------------- Comment 9: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-632) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for any proposed change): With things like role attribute and concept mapping with RDF you can assign a functional role to an element, That means that the assistive technology can themselves provide the correct help that is tailored to the user. the user experience is better because the help is tailored to their scenario Proposed Change: 2.5.4 Context-sensitive help is available for text input or the role of each control can be progmaticly determined ---------------------------- Response from Working Group: ---------------------------- The current success criterion does not prevent use of Accessible Rich Internet Application Specifications or other technologies to add information that will allow user agents or assistive technologies to provide context-sensitive help. We do not feel we need to specifically add "programmatically determined" to the success criterion in order to support this additional data, but we have added a placeholder for such technology-specific techniques. If additional information is programmatically provided in the markup and testing demonstrates that context sensitive help is provided to the user via the user agent or assistive technology, this success criterion has been satisfied. The technology-specific techniques should be provided for such technologies. We have provided some advisory techniques for the use of WAI-ARIA and will promote them as they qualify as accessibility supported in some environments. ---------------------------------------------------------- Comment 10: Source: http://www.w3.org/mid/141101c67f59$88036aa0$6400a8c0@IBM4CD7E5EACA1 (Issue ID: LC-633) http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/0137.html http://lists.w3.org/Archives/Public/public-comments-wcag20/2006May/att-0137/wcagform_ch2_.html Comment (including rationale for any proposed change): Most of this (at least at the higher levels) helps blind folks access error information. That is good. Clearly what is missing hear is a game plan for helping people with a learning disability , who have trouble filling in forms. Forms are real nightmears for a lot of us. In fact I often do not deposit checks and perform other tasks because of the barrier that form filling presents. Things that make it harder include short labels that do not explain what they are, coping numbers, Non expandable, small fonts. Too much information on one page. Information not being well grouped such as user information, payment information. Then with the short labels I get confused what is what. Server time outs. Asking a lot of information to make forms simpler to process but make form filling much harder and more complex. For example on this form on line it is much simpler (but PF preferred this table .. oh well) .... the options could be in a combo box as filled out meaningfully text... Proposed Change: Perform user testing with different groups of people with learning disabilities and cognitive limitations - including age related. Identify what technques help Add them ---------------------------- 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.
Received on Thursday, 17 May 2007 23:40:48 UTC