- From: Gregg Vanderheiden <gv@trace.wisc.edu>
- Date: Thu, 4 Nov 2004 11:34:10 -0600
- To: "'Andi Snow-Weaver'" <andisnow@us.ibm.com>, <w3c-wai-gl@w3.org>
Looks good Andi - thanks very much Only suggestion is for the last item. It may not be possible to check for spelling errors. Thus the IF needs to move up to front. It WAS 2. Where text entry is required, an option is provided to check for misspelled words. If possible for the natural language of the text, the spell checker makes suggestions for correct spellings. SUGGESTION 2. If possible for the natural language of the text, where text entry is required, an option is provided to check for misspelled words and suggestions for correct spellings are provided. Also I think this one 949 - Why does a Level 2 criterion require a Level 1 criterion to be met. Shouldn't it also require Level 2? could be closed with: "Only Level 1 criteria are required. Level 2 criterion can be selectively conformed to unless a full Level 2 claim is made." Gregg -- ------------------------------ Gregg C Vanderheiden Ph.D. Professor - Ind. Engr. & BioMed Engr. Director - Trace R & D Center University of Wisconsin-Madison -----Original Message----- From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Andi Snow-Weaver Sent: Thursday, November 04, 2004 6:05 AM To: w3c-wai-gl@w3.org Subject: Guideline 2.5 Issues Summary At the face to face meeting, I took the action to summarize all issues against guideline 2.5 and make a proposal to resolve as many as possible. Here is a link to the current issues summary for 2.5 http://trace.wisc.edu/bugzilla_wcag/issuereports/minimize-error_issues.php#8 85 This is a very long note organized in sections that are marked with beginning and ending indicators as follows: proposed wording current wording issues resolved by the proposal issues that I don't know how to solve issues recommended to be rejected <proposed wording> Guideline 2.5 Help users avoid mistakes and make it easy to correct them. [level 2 guideline] Level 1 Success Criteria for Guideline 2.5 1. No level 1 success criteria for this guideline. Level 2 Success Criteria for Guideline 2.5 1. If a user error is detected, the error is identified and provided to the user in text 2. If a user error is detected, and suggestions for correction are known and can be provided without jeopardizing security or purpose, the error is identified and the suggestions are provided in an accessible form that meets the other Level 1 success criteria. 3. Where consequences are significant and time-response is not important, one of the following is true: a. Actions are reversible. b. Where not reversible, actions are checked for errors before going on to the next step in the process. c. Where not reversible, and not checkable, the user is able to review and confirm or correct information before submitting it. Level 3 Success Criteria for Guideline 2.5 1. Where text entry is required for which there is a known set of less than 75 valid choices, and they can be provided without jeopardizing security or purpose, users are allowed to select from a list of options as well as to type the data directly. 2. Where text entry is required, an option is provided to check for misspelled words. If possible for the natural language of the text, the spell checker makes suggestions for correct spellings. Who Benefits from Guideline 2.5 (Informative) - Identifying typing errors helps individuals with writing disabilities and people with dyslexia who often have difficulty writing text in forms or other places that need text input. - Certain disabilities make it more difficult to operate input devices, resulting in more input errors. For example, individuals with limited motor functions are more likely to make errors when they operate a mouse or a keyboard. Speech recognition systems may find it more difficult to recognize the speech of individuals with speech disabilities. Features that assist in recognizing and correcting errors benefit individuals with these types of disabilities. Examples of Guideline 2.5 (Informative) Example 1: An airline web site offers a special promotion on discounted flights. The user is asked to complete a simple form that asks for personal information such as name, address, phone number, seating preference and e-mail address. If any of the fields of the form are either not completed or completed incorrectly, the user is warned of the input error. The user is then presented with the same form, all previously and correctly entered information is still available. The user is asked to make corrections to any form field marked with a red arrow or two asterisks. Note - color alone is not used to indicate errors. Example 2: A Web page requires the user to enter both a userid and password. If either is incorrect, the user is informed that there was an error but, for security reasons, is not informed as to which field, the userid or the password, is in error and suggestions for correcting are not offered. Example 3: A Web site provides an online test for certification in a particular field of study. The test identifies incorrect answers to the user but does not offer suggestions for correcting them. The purpose of the online test is to test the user's knowledge, therefore, providing hints on correct answers would go against the purpose of the Web site. Example 4: A web retailer offers online shopping for customers. When an order is submitted, the order information, including items ordered, quantity of each ordered, shipping address, and payment method, are displayed allowing the user to inspect the order for correctness. The user can either confirm the order or make changes. Example 5: A web retailer offers online shopping for customers interested in fly fishing gear. When the user is asked for his/her country, a pull down list of countries is offered instead of having the user enter the information by typing. To possibly make things easier, the user is informed that countries are listed in alphabetical order. Example 6: A search engine is provided with a variety of search options for different skill levels and preferences. It includes an option to check the spelling of the search terms and offers "best guess" alternatives, query-by-example searches, and similarity searches. Example 7: A banking Web site provides a form for customers to submit questions or suggestions. The form user interface includes an optional spell-checking feature for the text input area where the question or suggestion is entered. <end of proposed wording> <current wording> Guideline 2.5 Help users avoid mistakes and make it easy to correct them. [level 2 guideline] Level 1 Success Criteria for Guideline 2.5 1. No level 1 success criteria for this guideline. Level 2 Success Criteria for Guideline 2.5 1. If a user error is detected, the error is identified and provided to the user in text 2. If a user error is detected, and suggestions for correction are known and can be provided without jeopardizing security or purpose (for example, test validity), they are provided (in an accessible form that meets Level 1 success criteria). 3. Where consequences are significant and time-response is not important, one of the following is true: a. Actions are reversible. b. Where not reversible, actions are checked for errors before going on to the next step in the process. c. Where not reversible, and not checkable, the user is able to review and confirm or correct information before submitting it. Level 3 Success Criteria for Guideline 2.5 1. Where the input options are known, there are less than 75 of them, and they can be provided without jeopardizing security, test validity, etc, users are allowed to select from a list of options as well as to enter text directly. 2. Checks for misspelled words are applied and correct spellings are suggested when text entry is required. Who Benefits from Guideline 2.5 (Informative) - Identifying typing errors helps individuals with writing disabilities and people with dyslexia who often have difficulty writing text in forms or other places that need text input. - Certain disabilities make it more difficult to operate input devices, resulting in more input errors. For example, individuals with limited motor functions are more likely to make errors when they operate a mouse or a keyboard. Speech recognition systems may find it more difficult to recognize the speech of individuals with speech disabilities. Features that assist in recognizing and correcting errors benefit individuals with these types of disabilities. Examples of Guideline 2.5 (Informative) Example 1: a search engine. A search engine is provided with a variety of search options for different skill levels and preferences. It includes a spell checker and offers "best guess" alternatives, query-by-example searches, and similarity searches. <end of current wording> <issues resolved by the proposal> 565 - requests clarification of types of errors - examples added 642 - proposes for L2 SC 2 the following wording: errors are described and instructions or suggestions for correction are provided. - proposed wording above is: 2. If a user error is detected, and suggestions for correction are known and can be provided without jeopardizing security or purpose, the error is identified and the suggestions are provided in an accessible form that meets the other Level 1 success criteria. 694 - suggests adding an example of a feedback submission form that provides spell checking - added an example 863 - question about what "jeopardizing security" means. - I can only explain this by providing an example but I don't think this should be worked into the guideline itself. So the following two examples that have been added to the proposal above to explain jeopardizing security and purpose. Example for jeopardizing security: A Web page requires the user to enter both a userid and password. If either is incorrect, the user is informed that there was an error but, for security reasons, is not informed if it is the userid or the password and suggestions for correcting are not offered. Example for jeopardizing purpose: An online test identifies incorrect answers to the user but does not offer suggestions for correcting them. The purpose of the online test is to test the user's knowledge, therefore, providing hints on correct answers would go against the purpose of the Web site. 1047 - recommends adding "the other" to the phrase "... in an accessible form that meets Level 1 success criteria." in L2 SC 2. - proposed wording above incorporates this phrase: "... in an accessible form that meets the other Level 1 success criteria." 1098 - recommends that spell checking in L3 SC 2 should be an option that the user can exercise rather than being forced upon them. - proposal above addresses in the following re-wording: Where text entry is required, an option is provided to check for misspelled words. If possible for the natural language of the text, the spell checker makes suggestions for correct spellings. 1148 - points out that suggesting correct spellings is difficult in some languages such as Japanese. - proposal above addresses in the following re-wording: Where text entry is required, an option is provided to check for misspelled words. If possible for the natural language of the text, the spell checker makes suggestions for correct spellings. 1216 - questions what 75 input options means. Seems to be interpreting "input options" as "input methods" rather than "selectable choices of data". - proposal above addresses in the following re-wording: Where text entry is required for which there is a known set of less than 75 valid choices, and they can be provided without jeopardizing security or purpose, users are allowed to select from a list of options as well as to type the data directly. <end of issues resolved by the proposal> <issues that I don't know how to solve> 847 - recommends that we have specific success criteria for search functions. The DRC report recommends providing recommendations to improve search design but there is no detail on what the accessibility issues are with current search designs. Anybody know of any research in this area that we could leverage? 885 -This is a lofty goal but seems impractical and does not belong in this document. 949 - Why does a Level 2 criterion require a Level 1 criterion to be met. Shouldn't it also require Level 2? 1017 & 1047 - questions the number 75 in L3 SC 1. - This success criteria, as currently worded, says that for text entry fields that have a set of less than 75 known, acceptable entries, you must also provide a list of options from which the user can select. I'm not sure we really want that. There are plenty of sites that are accessible and usable that require you to enter one of 50 US states without also providing a selection list. Furthermore, the SC doesn't say anything about text entry fields that have 75 or more known, acceptable entries. Does the current wording imply that you can't provide a list of options if it's 75 or more? Or does it imply that the list of options is optional if you have 75 or more known entries? - I think perhaps this advice should go in the Gateway document. The point here is that, in general, providing selection lists enhances accessibility because it reduces typing and errors. But long selection lists can also create accessibility problems. Trying to create a testable success criteria for this is backing us into an absolute that I don't think we really want and certainly can't defend. 1215 - questions why the L2 SC 1 is not L1 SC <end of issues that I don't know how to solve> <issues recommended to be rejected> 851 - suggests adding to the "Who Benefits" section the following: Indentifying typing errors also helps individuals without disabilities to avoid time-consuming mistakes and general confusion. Helping all users to avoid mistakes increases a Web site's overall usability in addition to accessibility. - I think all discussion in the "Who Benefits" section should be about how people with disabilities benefit if a particular guideline is implemented. It is generally accepted that implementing accessibility requirements improves the usability for all users. The accessibility guidelines, however, should not go into detail as to how individual guidelines do this. 988 - suggests that the need for content to be separated from presentation should also be stressed in the case of error feedback - I think it should be assumed that anything the guidelines recommends has to be implemented in an accessible way without having to reiterate that point in every guideline. Otherwise, the Web page does not meet the guidelines. We already have added the phrase "in an accessible form that meets Level 1 success criteria" to one of the success criteria of this guideline. I think this is unnecessary. If you provide error notification to satisfy this checkpoint, then that is part of the function of your page and it has to meet all of the applicable criteria of the conformance level you are aiming for or else you don't meet that level of conformance. <end of issues recommended to be rejected> Andi andisnow@us.ibm.com IBM Accessibility Center
Received on Thursday, 4 November 2004 17:34:22 UTC