Summay of feedback on Guideline 2.5 proposals

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