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#885

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 12:10:57 UTC