RE: GL 2.5 Issues Summary and Proposal

At last week's telcon, we reached consensus on my proposal to resolve
issues 1343, 847, 1215, and 1344. SAP has concerns with the proposal to
resolve 1524 because all SAP transactions could be considered financial
transactions. The proposal was amended to read "legal or financial
transactions" and was accepted pending further feedback and recommendations
from SAP.

We decided not to accept the proposal for issue 1521 (new Level 3 success
criteria on providing examples of correct input when input must be provided
in a certain format). The proposed success criterion is a good usability
suggestion for all users. The proposal has been modified to reflect this
decision and the issue has been moved to the rejected issues section.

The remainder of this note is organized with beginning and ending
indicators as follows:

issues to be discussed
proposal
resolved issues
rejected issues
references

<issues to be discussed>

1017
- questions the number 75 in L3 SC 1.
- <als> See also the mailing list discussion starting 10 December, 2004
that ends with the proposal to separate Level 3 SC 1 into two SC. The
proposal to separate is included above but consensus was not reached on 10
and 75 as the thresholds [4].
- There was also a proposal from Yvette for making this more general but,
as worded, it would require authors to always provide choices if they are
known even if the number is large because the exclusion for large sets of
choices is in the techniques which are not normative. [3].
- No matter what thresholds we choose, there will be issues unless we have
some data to justify the numbers. Also, Jason indicated that with xforms,
the presentation is not under the control of the author and that user
agents will decide what is the most appropriate presentation mechanism. [5]
- I recommend removing this success criteria since it appears to be
technology dependent.

1351
- objects to Level 3 SC 2 on spell checking - conflicts with usability -
the decision to offer spell checking and to suggest correct spellings
should be left to the content author because the usability of the outcome
depends on many things including the quality of the dictionary, the
language used by the user which may be different from the language of the
page, and terms and names used.
- <als> Remove???

1396
- challenges the benefit claimed for identifying typing errors - it is
difficult for people with dyslexia to select the correct word from a list
of similar words.
- <als> Do we have any research data we can reference to justify this
benefit? If not, then I propose removing the benefit on identifying typing
errors.

<end of issues to be discussed>

<proposal>

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

No level 1 success criteria for this guideline.

Level 2 Success Criteria for Guideline 2.5

1. If an input error is detected, the error is identified and provided to
the user in text.

2. If an input 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 to the user in text.

3. For forms that cause legal or financial transactions to occur, that
modify or
delete
data in remote data storage systems, or that submit test responses, at
least 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. When user input is limited to a set of 10 or fewer known choices that
can
be provided without jeopardizing security or purpose, choices can be
selected from a list instead of, or in addition to, typing.

2. If there are more than 75 choices, selection lists must not be the only
means of providing the input choice. Another input method, such as a text
entry field, text typing to select items from list, or a search function,
must be provided instead of, or in addition to, the selection list.

3. 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 pulldown 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.

Example 8: Expected date format in a form.

In a form, there is a text box for "birthday". Next to this text box is the
text "(MM-DD-YYYY)" to indicate the format in which the date should be
entered.

<end of proposal>

<resolved issues>

1343
- suggests that we not use "user error"
- <als> In proposal above "user error" changed to "input error"

1524
- opened by me during this review as I noticed that Level 2 SC 3 is not
testable as currently worded. Proposed draft incorporated above.

<end of resolved issues>

<rejected issues>

847
- recommends that we have specific success criteria for search functions.
- <als> 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. I recommend we reject this issue and invite the DRC
to submit specific recommendations.
- at the 12 May 2005 telecon, the group agreed with rejecting this issue
and inviting the DRC to submit specific recommendations. I will contact the
DRC with this request.

1215
- questions why the Level 2 SC 1 is not  a Level 1 SC
- <als> I recommend this be rejected. The Level 2 SC here require visible
design changes and therefore do not fit our criteria for being Level 1.

1344
- recommends that all actions should be reversible and that even reversible
actions should be checked for errors
- <als> I agree that "many" actions "should" be reversible from a usability
perspective but I don't agree that it should be a requirement for
conformance to an accessibility spec. I therefore recommend rejecting this
issue.

1521
- proposes a new level 2 or 3 SC that assists users in entering correct
data in the first place
- <als> I propose this be a new Level 3 guideline because this is not
appropriate for all entry fields - only for those such as a telephone
number, date, social security number, etc. where a particular format is
expected.
- Yvette had a similar proposal to this one [3] - used Yvette's proposal as
the basis for the new SC incorporated in draft above and added her last
example
- at 12 May 2005 telecon, the group agreed not to add this success
criterion as it is a usability problem for all users, not a unique one for
users with disabilities.

<end of rejected issues>

<references>

[1]
http://trace.wisc.edu/bugzilla_wcag/issuereports/minimize-error_issues.php
[2] http://www.w3.org/WAI/GL/WCAG20/#minimize-error
[3] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004OctDec/0327.html
[4] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004OctDec/0558.html
[5] http://lists.w3.org/Archives/Public/w3c-wai-gl/2004OctDec/0598.html

<end of references>

Andi

Received on Wednesday, 18 May 2005 01:49:31 UTC