RE: Action Item: Additional Examples Guideline 2.5 (user error)

I have a few comments on the user error guidelines- thanks Doyle for
doing the hard work!
Gian

<snip>
Guideline 2.5 Help users avoid mistakes and make it easy to correct
them.
[level 2 guideline]
</snip>
<gian>
- how about a level 1 success criteria is to provide a "Reset" button -
so users can easily correct and mistakes
</gian>

<snip>
 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.
</snip>
<gian>
- Is 75 an arbitrary number?  What about those fields that specify
Country (such as: http://www.microsoft.com/worldwide/) or very complex
forms (such as:
http://www.microsoft.com/Usability/enrollment.htm)</gian>
</gian>

<snip>
1.         If a user error is detected, the error is identified and
provided
to the user in text
</snip>
<gian>
- does this success criteria allow this information to be provided via a
dialog box - if so, what about accessibility concerns re popup windows
etc? (such as:
http://www.liveinvictoria.vic.gov.au/web13/Site.nsf/contactUs?OpenForm)
Do we want to allow this?
</gian>
 
<snip>
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).
</snip>
<gian>
Suggested rewrite:
If a user error is detected, suggestions for correction are provided in
an accessible manner, where:
- valid entries are known
- security is not jeopardised
- purpose is not undermined
 </gian>

<snip>
Allowing users to select an option from a list instead of having to
enter
text directly helps individuals with speech disabilities because they
might
not be recognized properly in voice input applications.
</snip>
<gian>
Also assists people with physical disabilities, dyslexia etc who may
spell a word incorrectly.
</gian>

<snip>
An airline web site offers a special promotion on discounted flights.
The
user is asked to fill out a simple form that asks for personal
information
such as name, address, phone number, seating preference and e-mail
address.
When the user submits the form with a form field not filled in, the user
is
notified there is an error but all correct information from the previous
form stays unchanged.  This prevents the user from having to re-enter
all of
the previous information.
</snip>
<gian>
should we specify *how* the user is notified (ie with dialog box, text,
HTML page etc)
</gian>
 
<snip>
Example 3: online form (same form but a different scenario)
An airline web site offers a special promotion on discounted flights.
The
user is asked to fill out 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 filled out or filled out
incorrectly, the user is warned of the input error.  The user is now
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.
</snip>
<gian>
I don't really understand the difference between this example and
example 2.
</gian>
 
<snip>
Example 4: pull-down selections
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 fill in the
information
by typing. To possibly make things easier, the user is informed that
countries are listed in alphabetical order.
</snip>
<gian>
but this may invalidate the 75 input rule (see above)
</gian>
 
<end of message>

Received on Thursday, 13 May 2004 00:18:36 UTC