- From: Andi Snow-Weaver <andisnow@us.ibm.com>
- Date: Thu, 11 Nov 2004 14:56:10 -0600
- To: w3c-wai-gl@w3.org
- Cc: gv@trace.wisc.edu, caldwell@trace.wisc.edu
Thanks to Gregg and Ben for some good comments on my proposals for guideline 2.5. I have summarized their comments here and followed them with the complete text of the new proposed wording for guideline 2.5. L2 SC 2 current proposed wording: 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. Ben suggests editorial change for consistency with other guidelines. New proposed wording: 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 WCAG 2.0 at Level A. L3 SC 2 current proposed wording: 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. Gregg suggests that it might not be possible in all languages to even check for misspelled words. New proposed wording: 2. If possible for the natural language of the text, an option is provided to check text entries for misspelled words with suggestions for correct spellings. Examples Ben suggests examples each include a short title for consistency with other examples. Incorporated into complete text of new proposed wording below. Example 2 current proposed wording: Ben suggests that "username" might be more common or easier to understand than "userid" 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. new proposed wording: Example 2: A Web page requires the user to enter both a username 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 username or the password, is in error and suggestions for correcting are not offered. Example 6 current proposed wording: 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. Ben suggests that spell checking should be automatic for search engines but optional for more extensive text entry fields such as the feedback from in example 7. But that would be going beyond compliance and developers may be confused about when they should automatically do it and when they should provide an option. I would rather make the example a little less specifica and word it simply as: Example 6: A search engine provides features that offer spell checking, "best guess" alternatives, query-by-example searches, and similarity searches. <complete text of new 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 WCAG 2.0 at Level A. 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. If possible for the natural language of the text, an option is provided to check text entries for misspelled words with 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: Identifying errors in a form submission. 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: Username and password errors. A Web page requires the user to enter both a username 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 username or the password, is in error and suggestions for correcting are not offered. Example 3: An online test. 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: Order confirmation. 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 selection list to reduce errors. 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: Search engine features. 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: Spell checking in feedback forms. 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 complete text of new proposed wording> Andi andisnow@us.ibm.com IBM Accessibility Center (512) 838-9903, http://www.ibm.com/able Internal Tie Line 678-9903, http://w3.austin.ibm.com/~snsinfo
Received on Thursday, 11 November 2004 20:56:22 UTC