- From: Loretta Guarino Reid <lorettaguarino@google.com>
- Date: Thu, 17 May 2007 16:42:54 -0700
- To: "Robert C. Baker" <Robert.C.Baker@ssa.gov>
- Cc: public-comments-WCAG20@w3.org
Dear Robert C. Baker , Thank you for your comments on the 2006 Last Call Working Draft of the Web Content Accessibility Guidelines 2.0 (WCAG 2.0 http://www.w3.org/TR/2006/WD-WCAG20-20060427/). We appreciate the interest that you have taken in these guidelines. We apologize for the delay in getting back to you. We received many constructive comments, and sometimes addressing one issue would cause us to revise wording covered by an earlier issue. We therefore waited until all comments had been addressed before responding to commenters. This message contains the comments you submitted and the resolutions to your comments. Each comment includes a link to the archived copy of your original comment on http://lists.w3.org/Archives/Public/public-comments-wcag20/, and may also include links to the relevant changes in the updated WCAG 2.0 Public Working Draft at http://www.w3.org/TR/2007/WD-WCAG20-20070517/. PLEASE REVIEW the decisions for the following comments and reply to us by 7 June at public-comments-WCAG20@w3.org to say whether you are satisfied with the decision taken. Note that this list is publicly archived. We also welcome your comments on the rest of the updated WCAG 2.0 Public Working Draft by 29 June 2007. We have revised the guidelines and the accompanying documents substantially. A detailed summary of issues, revisions, and rationales for changes is at http://www.w3.org/WAI/GL/2007/05/change-summary.html . Please see http://www.w3.org/WAI/ for more information about the current review. Thank you, Loretta Guarino Reid, WCAG WG Co-Chair Gregg Vanderheiden, WCAG WG Co-Chair Michael Cooper, WCAG WG Staff Contact On behalf of the WCAG Working Group ---------------------------------------------------------- Comment 1: Source: http://www.w3.org/mid/7BB274B2F849DE4981915D42210ED48F028EE0EA@s3c1ex1.ba.ad.ssa.gov (Issue ID: LC-681) The Social Security Administration welcomes the opportunity to comment on the proposed WCAG 2.0 standards. In general, SSA finds that the general content of the proposed standards addresses many shortcomings of the previous version of the standards. In addition, the baseline concept for establishing a testing environment provides excellent direction for accessibility and validation testing. However, SSA has some concerns that should be addressed before the final version is published. § The principles are broken down into 4 simple components – perceivable, operable, understandable and robust, which we agree is an excellent way to structure the standards at a high level. However, the explanations and further breakdown tend to be confusing and navigation through the 400 plus pages is unwieldy. As a result - it can be difficult to determine if appropriate standards exists to guide development activities. § Specific techniques for meeting the guidelines are very scientific and precise, however from a pragmatic perspective will be difficult to implement due to focus on mathematic calculations to address unfamiliar issues such as luminosity and audio levels. § Success criteria in some cases are very general and in need of further definition to support proper implementation (for example: minimal level of accessibility is defined as the target - but the criteria for meeting this requirement are not defined). § The guidelines do not address the following: § Alt text for images, links, etc. that are normally exposed by mouse over capabilities must also be accessible by the keyboard. § For error handling, there must be a way for users to know where errors are in a form and be able to navigate directly to the input in error. § Guidelines for creating HTML documentation and Help must be stated and Help using navigational techniques must also be documented for accessibility. § Informational text and instructions within web applications must have a focal point achieved by using tab indices of zero or some equivalent technique. § Applets and plug-ins used with web pages or applications must be referenced with specific guidelines for accessibility. § Standardized keyboard navigation through frames. § Search facility guidelines for navigation and focus. § Mark-up of textual information for carets and other pointers. § Avoiding conflicts between browser and web application commands. § In addition, we recommend the W3C address the following items at a later date: § Guidelines should provide additional guidance and examples are needed to address user navigation to errors once they are identified. § Guidelines should address keyboard access, however additional guidance is needed for when to assign hotkeys, defining logical tab order, hotkeys shown on buttons, and defining tab indices for text focus and search functionality. Also, guidance is needed to determine what is an acceptable number of keystrokes to perform the equivalent of one mouse action to provide comparable access. § Guidelines should address e-learning considerations, such as navigation, registration, administration, courseware, simulations, test taking, and reporting results. § Guidelines should address context sensitive help built into the HTML structure. § Guidelines should address table navigation for magnification users. Respectfully, Robert Baker ---------------------------- Response from Working Group: ---------------------------- ----------------------------------------------------------------- § The principles are broken down into 4 simple components – perceivable, operable, understandable and robust, which we agree is an excellent way to structure the standards at a high level. However, the explanations and further breakdown tend to be confusing and navigation through the 400 plus pages is unwieldy. As a result - it can be difficult to determine if appropriate standards exists to guide development activities. § Specific techniques for meeting the guidelines are very scientific and precise, however from a pragmatic perspective will be difficult to implement due to focus on mathematic calculations to address unfamiliar issues such as luminosity and audio levels. § Success criteria in some cases are very general and in need of further definition to support proper implementation (for example: minimal level of accessibility is defined as the target - but the criteria for meeting this requirement are not defined). We agree with this assesment and have created the QUICK REFERENCE document (http://www.w3.org/WAI/WCAG20/quickref/). We believe that this will address your concern by putting the requirements and a succinct list of techniques for meeting them all in one document. The sufficient techniques are very concrete and have full descriptions, examples and tests associated with them. With regard to the technique requiring calculation, we provide links to free tools that will automatically carry out the calculations and evaluate content for you. In the past we only said things like "use sufficent contrast" which provided no guidance and did not allow authors to ever determine if they had met the guideline or not. ----------------------------------------------------------------- § Alt text for images, links, etc. that are normally exposed by mouse over capabilities must also be accessible by the keyboard. Keyboard operations requirement and alt text are already in the guideline at level A. Assuming content meets WCAG 2.0, it is the user agent that determines if alt text can be exposed by keyboard only. If a 'mouseover' event is used in scripting then SC 2.1.1 would require that moving the focus to the item by keyboard would also trigger the same action as mouseover. So the concern is either met (in one case) or a user agent issue (in the other case). ----------------------------------------------------------------- § For error handling, there must be a way for users to know where errors are in a form and be able to navigate directly to the input in error. The working group considered adding this requirement as a success criterion, and decided not to because it is too specific to apply to all technologies and all environments. However, there are several advisory techniques provided that will help authors who wish to design more usable forms. ----------------------------------------------------------------- § Guidelines for creating HTML documentation and Help must be stated and Help using navigational techniques must also be documented for accessibility. We agree that Help and documentation that is available *on the web* is web content and hence that it should conform to these Guidelines. Note that although the same issues appear for documentation and Help files for desktop applications, these guidelines do not address that content. However, we feel that attempting to single out specific examples of Web content is likely to lead people to believe that only the listed examples are covered. ----------------------------------------------------------------- § Informational text and instructions within web applications must have a focal point achieved by using tab indices of zero or some equivalent technique. The working group believes that there are some instances where deliberately putting focus on something (like error messages) can be helpful, but that attempting to control the way a user interacts with all pages, especially where it may conflict with expected behaviors for forms or other user interface components, is problematic. ----------------------------------------------------------------- § Applets and plug-ins used with web pages or applications must be referenced with specific guidelines for accessibility. Programmatic content (applets, etc.) are covered in several ways. If they are not accessibility supported, then conformance requirement6 requires that the inaccessible content do no harm and conformance requirement 4 requires that an accessible version also be provided. If the technologies are accessibility supported, then SC 4.1.2 requires that the programmatic content be compatible with assistive technologies and be accessible. In addition, all of the other success criteria (such as keyboard operability) in the guidelines would also need to be met by the programmatic content. The term "plug-in" is usually used for extensions to user agents, and is related to the definitions of "user agent" and "assistive technology". Guidelines related to the accessibility of plug-ins themselves can be found in the User Agent Accessibility Guidelines (http://www.w3.org/TR/UAAG10/). ----------------------------------------------------------------- § Standardized keyboard navigation through frames. The success criteria in guideline 2.1 require that all content be operable via the keyboard. How user agents provide keyboard navigation through frames is a user agent issue. ----------------------------------------------------------------- § Search facility guidelines for navigation and focus. While this can be helpful for improving the experience with Windows Narrator, more fully-featured screen readers have the ability to allow users to interact with all kinds of text. Users of those screen readers are used to the way they interact with structured pages, and don't need this extra help. In addition, there are many issues for other types of users with this non-standard approach. For example, 1) Unexpected behavior for all users 2) Developers often attach events to paragraphs and other non-actionable elements when they have focus, and this is not compatible with AT. 3) This will be more difficult for sighted keyboard users, as they will have to tab through parts of the page that are not normally tabbable. 4) Confusing for experienced screen-reader users, because they expect that everything tabbable in a form is an editable field 5) Optimized for forms mode, but also used on non-form pages. This is very strange when in browse mode, because users expect to be able to tab to find links. ----------------------------------------------------------------- § Mark-up of textual information for carets and other pointers. The user agent issue is, of course, outside of our guidelines and would be in the domain of the user agent guidelines. From a content perspective, any non-text content must have text equivalents under SC 1.1.1. Structure (lists etc.) must be programatically determinable under SC 1.3.1. Other use of characters that convey information required to understand and operate content should be addressed by SC 1.3.3 (formerly 1.3.5). ----------------------------------------------------------------- § Avoiding conflicts between browser and web application commands. We will be adding an advisory technique titled "Avoiding use of common user-agent keyboard commands for other purposes." ----------------------------------------------------------------- § Guidelines should provide additional guidance and examples are needed to address user navigation to errors once they are identified. There are advisory techniques for SC 2.5.3 that cover much of the SSA recommendations. They include. -Validating form submissions on the server (future link) -Re-displaying a form with a summary of errors (future link) -Providing error notification as the user enters information (future link) -Assisting the user in making corrections by providing links to each error (future link) -Highlighting or visually emphasizing errors where they occur (future link) -Supplementing text with non-text content when reporting errors (future link) In addition, we are adding the following advisory techniques. -"Placing focus in the field containing the error" -"Avoiding use of the same words or letter combinations to begin each item of a drop-down list" And we have linked this SC to the following advisory technique: "Providing client-side validation and alert" NOTE: "(future link)" is what we call all techniques that we have identified and are listed in our "Understanding WCAG" and our "Quick Reference" documents but have not yet been fully written up. ----------------------------------------------------------------- § Guidelines should address keyboard access, however additional guidance is needed for when to assign hotkeys, defining logical tab order, hotkeys shown on buttons, and defining tab indices for text focus and search functionality. Also, guidance is needed to determine what is an acceptable number of keystrokes to perform the equivalent of one mouse action to provide comparable access. This type of topic would be handled in an application notes. We would love to write an Application Note "Enhancing Keyboard Access to Web Content" that would provide guidance on assigning hotkeys, defining logical tab order, defining hotkeys shown on buttons, and defining tab indices for text focus and search functionality. It might also discuss the topic of "number of keystrokes to perform the equivalent of one mouse action" but it won't be able to define "comparable access" since it would differ so much based on individual abilities to point or create keystrokes. User agent support for access keys is so bad that developers have started looking for server-side solutions that allow users to define access keys (see http://juicystudio.com/article/user-defined-accesskeys.php and http://juicystudio.com/article/user-defined-access-keys-aspversion.php). If you are aware of a good paper or application note on this we would be most interested. ----------------------------------------------------------------- § Guidelines should address e-learning considerations, such as navigation, registration, administration, courseware, simulations, test taking, and reporting results. We belive that all of the fundamental issues raised in making these applications accessible are included in the guidelines. The guidelines cover form controls, text, images, multimedia and programmatic elements (applets and the like). The EO group working with WCAG WG will be working on application notes to look at particular applications in the future and we expect that additional techniques in this area will become available in the future. However, the basics should already all be in place. ----------------------------------------------------------------- § Guidelines should address context sensitive help built into the HTML structure. Thank you, we have added an advisory technique (which will be completed at later date) titled "Using the title attribute to provide context-sensitive help" and another titled, "Using scripts to provide context-sensitive bubble help." ----------------------------------------------------------------- § Guidelines should address table navigation for magnification users. Success criterion 1.3.1 includes requirements related to the use of table markup. The working group believes that this is a user agent issue rather than a content issue. If you have suggestions for techniques that would improve table navigation for screen magnification users, please submit them so we can include them. (Refer to the techniques submission form at http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/).
Received on Thursday, 17 May 2007 23:43:21 UTC