Edit comment LC-681 for Accessibility Guidelines Working Group

Quick access to

Previous: LC-1442 Next: LC-731

Comment LC-681: Comment Shortname:; Commenter: Robert C. Baker <Robert.C.Baker@ssa.gov> on behalf of Social Security Administration; Message-id:; Section of the document concerned:

or; Refinement of the section concerned:; Status:
assigned to; Type:; Resolution status:
Response drafted Resolution implemented Reply sent to commenter; Response status:
No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):; Comment:
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; Related issues: (space separated ids); WG Notes: [EDITORZ] BBC Relates to issues LC-718 through LC-731 Individual items have been given their own issue number, but general comments recorded here. SENT LETTER ASKING FOR CLARIFICATIONS ====================================== From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] Sent: Sunday, July 02, 2006 10:09 PM To: Robert.C.Baker@ssa.gov Subject: Hi Robert Greg, See SSA comments in red below [MARKED SSA: ] Robert Baker SSA Section 508 Coordinator 410 966-7602 -----Original Message----- From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu] Sent: Sun 7/2/2006 11:08 PM To: Baker, Robert C. Hi Robert Thanks for your comments. We are having a little trouble processing some of them. For some of the questions we aren't sure exactly what you are referring to - or what you would like added. Below are the two sections we are having trouble with along with our questions. If you could provide some additional information - and specifically what you think should be added it would be most helpful. Thanks much ---------- 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. * This one is clear. Â§ 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. * This is clear also. Â§ Guidelines for creating HTML documentation and Help must be stated and Help using navigational techniques must also be documented for accessibility. * Do not understand this one. If the documentation is on the Web, it is covered by the guidelines. For the last part are you just saying that there must be a help file on each page that says how to navigate that page? Can you explain more and give us an example of what you think should be on each web page? SSA: SSA has found that vendors supplying documentation for products do not have a clear understanding of what is required for accessible electronic documentation. Often documentation is supplied in PDF format and is determined to be not accessible. Vendors will then just convert to HTML and think they are done with it. It is likely that the WCAG guidelines do cover documentation and Help facilities but it is felt that a separate section dedicated to Help and documentation would help to clarify this situation. Documentation and Help can be presented in many formats. These include straight text, a Microsoft or RoboHelp type Help facility with frames such as Content, Index and Search, an interactive documentation capability where there is a table of contents and the user is able to move around a document and finally links to context sensitive Help on the same HTML page. The issues that are involved include: - Equivalent alt text for images - Ability to move automatically to a content frame when a link is selected from a different frame - Elimination of A-Z links for index as it requires significant keyboarding to be replaced by drop downs - Selection of objects moving directly to the object of the selection and therefore a change in focal point - Ability to move back to original focus when a Help link is selected - HTML capability to select context sensitive help for a field through keystrokes Â§ Informational text and instructions within web applications must have a focal point achieved by using tab indices of zero or some equivalent technique. * Do not understand this one. What do you mean by "a focal point". Do you mean that if I hit page up until I hit the top of the page (or some other method to get to the top of the page) I will always end up at some starting point? Isn't this always true? Are you asking for something else? Please explain more and provide an example. Thanks SSA: Navigating through web applications with the tab key works fine for controls and is expedient for a keyboard user. However, there are many instances where there are error messages, informational text, instructions, etc. displayed as static text. This is often missed by users who are blind when tabbing through an application and by screen magnification keyboard users. SSA applies tabindices to the text to put focus on these areas so that screen readers speak it and screen magnifiers display it. This causes HTML validators to hiccup, so we are asking for a capability to supply this so that information is not missed. Â§ Applets and plug-ins used with web pages or applications must be referenced with specific guidelines for accessibility. * This is clear. Â§ Standardized keyboard navigation through frames. * This is controlled by the user agent not the content. So it would fall under User Agent Guidelines not content guidelines. Does that make sense to you? Â§ Search facility guidelines for navigation and focus. * We are not sure we understand this one. We have guideline and techniques covering certain aspects of navigation and focus. We will be doing application notes later. One would be on 'Basics for creating accessible Web pages'. If we covered navigation and focus in that application note and explained how to use sufficient and advisory techniques to match it - would that meet the need you are raising? SSA: Again, this is a big issue of focus. Search facilities are used extensively in web pages and applications. However, identifying the results of a Search is hit or miss depending on where the focus is applied. In some cases, after a Search is initiated, the focus is placed back in the Search input box, so the user may think that it did not work. Often, the focus is at the top of the page and the user has to tab or arrow through significant controls or text to get to the results of the Search. SSA suggests that there be a capability or guideline to move the focus to the results of a Search. That is "No Hits Found" or 1-10 of 85,000,000. Â§ Mark-up of textual information for carets and other pointers. * Not sure on this one. If you mean graphic carets etc - they are covered under 1.1 which says that ALL non-text content must have text equivalents. If you mean text characters, -- well they are already text so I guess that isn't the problem. Does 1.1's requirement for text alternative for all graphics, and 1.3's requirement for content to be separable from presentation - (which would mean all bullets (lists) would need to be evident programmatically) - address your concern here? If not could you tell us more and give us an example that contains carets and other pointers so we can see what you mean? SSA: This is another extension of the issue with focal point. It is probably more of an issue with the user agent or browser. Browsers that supply an actual caret indicating where focus is can make web pages and applications easier to navigate like fat clients, word processors etc. Â§ Avoiding conflicts between browser and web application commands. * This again would be a user agent (browser) issue we think. Web apps of course are content but if you don't know which browser they are using it is hard. And this would be a problem for all users would it not? Not just people with disabilities? Would an advisory technique like "Using keyboard commands in Web applications that do not conflict with common browser keyboard commands" address your concern here? SSA: That would probably suffice but it is difficult to keep up with this. For example, SSA uses ALT + P in its Internet applications to move to the Previous page. In IE 7 ALT + P is now used for a Page capability, making this command not accessible. Add buttons are very difficult to provide hotkeys for as ALT + A and ALT + D are taken by the browsers. It might work, however, if pressing ALT + A could toggle through the various controls or provide other means to address. Additionally underlined hotkeys on buttons is not available in HTML (except through JavaScript) so that it is difficult to let sighted keyboard users know what the keys are. Â§ In addition, we recommend the W3C address the following items at a later date: * By later date - do you mean after the guidelines come out? For example, handling these topics in application notes that the education and outreach group is creating? SSA: Yes * The application notes tell you how to do things with references to the techniques and the guidelines. They do not focus on what you do to conform at various levels but rather they focus on telling a cogent story on how to do something. The SC and levels are mentioned but only co-incidentally. The goal is to lay out how to address accessibility along some dimension. Â§ Guidelines should provide additional guidance and examples are needed to address user navigation to errors once they are identified. * Could this be part of a basic Application note? SSA: Yes Â§ 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. * Could this be part of an application note on maximizing keyboard access? SSA: We would rather see this as a general guideline. This also relates to comparable access which isn't really addressed but needs to be quantified. Â§ Guidelines should address e-learning considerations, such as navigation, registration, administration, courseware, simulations, test taking, and reporting results. * An application note on e-learning ? SSA: This would take a substantial effort but is needed. Â§ Guidelines should address context sensitive help built into the HTML structure. * Part of application note on enhancing/maximizing cognitive access? SSA: See Help and documentation comments Â§ Guidelines should address table navigation for magnification users. * Don't understand this one. With proper table markup (which is required) wouldn't a screen magnifier be able to tell the user where they are? Can you elaborate on your issue? Or would this address your issue? Do you have other ideas? SSA: This applies to a screen magnification user who primarily uses the keyboard. If the user is in a cell and magnification is at 4-6X, there is no easy way to understand what the row and/or column header is. First, there has to be a way to navigate and get focus on a cell and then there needs to be a way for the column and row headers to be displayed. SSA has made attempts to expose this through JavaScript but there is still the issue of navigating through an HTML table with a keyboard. Screen readers take care of this but we cannot always rely on the assistive technologies to provide virtual cursors, keystrokes, etc. We also cannot count on a specific user agent to account for this. For Internet applications, agencies would have to trust all browsers to have identical capabilities. Thanks. Gregg ---------------------- Co-chair @@@@ Compile answers from issues LC-718 through LC-731 into this answer}}}}; Resolution: ----------------------------------------------------------------- Â§ 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/).; (Please make sure the resolution is adapted for public consumption)