- From: Michael Cooper <cooper@w3.org>
- Date: Wed, 25 Oct 2006 16:21:00 -0400
- To: List WAI GL <w3c-wai-gl@w3.org>
- Message-ID: <453FC72C.8030403@w3.org>
* Lots of SC about error recovery but none about error prevention
(several comments)
* Better supports for error recovery
o Navigate directly to error
o Separate identification of the bad data from explanation of
how it is bad
* Where is it useful to inform user of errors?
* Context-sensitive help required for all inputs, even though they
have labels? A suggestion to narrow to ones that have wide ranges
of options
* Accuracy of system determination there is an error state
* Suggestions for error prevention
o Good labeling
o Check for errors before moving to next stage
o Re-present input for review
* Request server-side techniques
*Comment LC-568*
*Sort Terms:* cognitive -errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* Roger Hudson <rhudson@usability.com.au>
*Comment Type:* substantive
*Location:* minimize-error
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error>
*Comment:*
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
Guideline 2.5 states, \"Help users avoid mistakes and make it easy to
correct mistakes that do occur.\" The Level 1 and Level 2 Success
Criteria for this Guideline all appear to be concerned helping people
recover from mistakes. The only SC that relates to avoiding mistakes in
the first place is a Level 3 criterion.
Proposed Change:
I suggest the Working Group consider including more information on how
mistakes can be avoided. At the least, Success Criteria 2.5.4 should be
a Level 2 criterion.
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
Discussed at Team C call 30 May, 2006
http://www.w3.org/WAI/GL/2006/05/30-wcag-teamc-minutes#item04
We recommend rejecting this comment. The working group discussed this
issue many times. While we all agree that providing help is generally a
good idea, we could not come to consensus on a success criteria that
would be applicable to all websites which is our requirement for Level 1
and 2. SC 2.5.3 #3 does provide one success criteria at Level 2 for
helping users avoid mistakes in certain situations. So we do have
something small at Level 2 for helping users avoid mistakes.
We do recommend, however, adding an advisory technique on providing help
information to "Understanding Guideline 2.5"
<proposal>
[REJECT]
Providing help is generally a good idea but may not be applicable to all
websites. Our criteria for SC at Level 1 or 2 is that it has to be
applicable to all websites. The Level 2 SC 2.5.3 # 3 does have a
requirement for helping users avoid mistakes in certain situations. And
we will be adding an advisory technique on providing help information to
the "Understanding guideline 2.5" information.
</proposal>
01 June 2006
resolution: 568 - give this a short name cognitive-errors. send back
http://www.w3.org/WAI/GL/2006/06/01-wai-wcag-minutes.html
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-16 16:10:01
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/568>*
------------------------------------------------------------------------
*Comment LC-719*
*Sort Terms:* errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* Robert C. Baker
<<Robert.C.Baker@ssa.gov>> *Affiliation:* Social Security Administration
*Comment Type:* substantive
*Location:* minimize-error
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error>
*Comment:*
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
(See LC 681 for complete submission)
The guidelines do not address the following:
§ For error handling, there must be a way for users to know where errors
are in a form and be able to navigate directly to the input in error.
Proposed Change:
*Status:* open
*Working Group Notes:* [TEAMC]
Several of the advisory techniques address this. Does anyone remember
why we decided not to make an SC about finding the fields with errors?
*Resolution Working Notes - Unapproved:*
[reject]
The working group considered adding this requirment as a success
criterion, and decided not to because [add reason here]. However, there
are several advisory techniques that will help authors who wish to
design more usable forms.
*Related Issues:*
*Assigned To:* Cynthia Shelly
*Last Edited:* 2006-10-16 15:17:42
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/719>*
------------------------------------------------------------------------
*Comment LC-757*
*Sort Terms:* Errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* Jessica Enders <jessicae@hiser.com.au> *Affiliation:*
The Hiser Group
*Comment Type:* substantive
*Location:* minimize-error-context-help
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error-context-help>
*Comment:*
Part of Item:
Comment Type: TE
Comment (including rationale for proposed change):
This Criterion states that \"Context-sensitive help is available for
text input\". The accompanying advice on how to meet this criterion
seems to suggest that such help must be available for ALL text input
fields.
If it is sufficient, to meet this criterion, to have clear labels for
all text input fields, then you can ignore my comments here. However, if
the guidelines are suggesting that there needs to be specific help text
for every text-entry field, AS WELL AS a clear label, then please read on!
As a professional and experienced questionnaire designer, I feel this is
unreasonable and may in fact hinder usability for all users, not just
those with a disability, and reduce data quality.
It is well documented that providing examples for a question can, in
fact, reduce the accuracy of the response because users tend to limit
their thinking to just those provided examples. Moreover, good form
design notes that the information required to provide a response should
ideally be located with the label for that response field (ie don\'t
separate instructions from the relevant questions). As such, authors
should be incorporating all the information that is needed into the
label/question, rather than providing some information in a separate area.
Add to this the fact that there isn\'t much useful help that can be
added to many text fields. For example, what help would you give for
your own text field \"Proposed Change\" below? Adding text along the
lines of \"Please type here a description of the change that you think
we should make\" is superfluous, patronising and degrades the user
experience. Please let us not return to the bad old days where even
fields such as \"Family Name\" had an instruction that consequently made
users feel like idiots, and contributed to the instruction blindness
that is prevalent today.
Proposed Change:
Reword the criterion or its associated documentation to make it clear that:
- in all cases, the label for the text entry field must clearly
communicate what sort of information should be provided in the field
- additional context-sensitive help need only be provided where it is
reasonably required to explain what is to be entered, or to minimise the
burden on the user.
*Status:* open
*Working Group Notes:* [TEAMC] []
She has a good point. I can't see how we can add a test for obviousness
without making the checkpoint untestable. However, I think we could
clarify some things in how-to-meet. I'd add her two bullet, plus
something like:
- in most cases, context sensitive help should not be placed in the form
itself, but should instead be available to users when they request it.
For example, by linking to a separate help file.
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Cynthia Shelly
*Last Edited:* 2006-09-14 05:16:56
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/757>*
------------------------------------------------------------------------
*Comment LC-978*
*Sort Terms:* Errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* Al Gilman <Alfred.S.Gilman@IEEE.org>
*Comment Type:* substantive
*Location:* minimize-error-identified
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error-identified> ("error
is identified")
*Comment:*
unenforceably vague
Proposed Change:
"item which system feels to be in error is identified."
*Status:* open
*Working Group Notes:* [TEAMC] []
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-09-14 05:16:59
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/978>*
------------------------------------------------------------------------
*Comment LC-979*
*Sort Terms:* errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* Al Gilman <Alfred.S.Gilman@IEEE.org>
*Comment Type:* substantive
*Location:* minimize-error-identified
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error-identified> ("in
text" + level)
*Comment:*
Identifying the bad entry is enough so long as the entry is
prompted/labeled adequately. In other words affordance of help
recovering from data entry errors is good advice, but too demanding at a
Level 1 success criterion standard.
Also, authors just get this wrong too easily. How many times does the
text explanation say "bad password" when the error was in the username?
Error explantions should follow the culture of the desktop. If there is
a screen reader in use, this is the screen reader's habits for
expressing error messages. The content should define the error as
formally as they can. Let the UA and AT worry the friendly message.
If the UA knows it is a type error and the type is identified, then that
is enough to synthesize an error explanation in diction the user will
understand in the culture of their desktop formed by their AT.
System codes would not make that error. The point is that the server
refused the authentication information pair of username *and* password.
Proposed Change:
Separate identification of the bad data from explanation of how it is
bad. Move explanation of nature of error to lower level. Allow
satisfaction by either text message or metadata understandable by user's
automation.
*Status:* open
*Working Group Notes:* [TEAMC]
The SC says: "If an input error is detected, the error is identified and
described to the user in text"
Al is saying we are requiring an "explanation" and he is suggesting we
move the requirement for that explanation to a lower level. However, we
are simply requiring that the error is "described" to the user, that she
be able to understand it. The "Gage Dictionary" defines an "explanation"
as a "detailed description" we are not requiring a detailed description.
But simply a description. I think that description should remain at
level 1.
The intent section says:
"The intent of this success criterion is to ensure that users are aware
that an error has occurred and can determine what is wrong."
I think it entirely reasonable that we require a description of the
error such as "error: use only numbers" for a telephone field that was
filled with letters, rather than "an error has occurred". We have been
getting criticism for the (understandable) lack of support for cognitive
issues. THis is one place where we are helping cognitive issues. And as
such I think we need to keep it.
ANDI adds: Regarding 979, I think we should also address the concern,
"Allow satisfaction by either text message or metadata understandable by
user's automation.". This also came up in issue 629. Can we include the
response from 629 in this response as well?
David responds: yes, I have added the text of 629's response to this
one. Although currently the SC requires satisfaction.
Becky adds:
The better way to address his concern might be in the how to meet
section by explaining the error should be specific as possible. We might
also want to include and example that allows the AT to present the user
with the information.
I don't know of any AT today that extracts error messages and presents
them in a cutom format for the person with the disability. I was going
to add an example of this but
*Resolution Working Notes - Unapproved:*
[partial accept]
@@add to the How to meet document intent section:
"The error message should be as specific as possible."
write:
As per your suggestions, in the "how to meet" document we have added
that the error should be specific as possible.
The WG does not think we should move the "explanation" of the nature of
the error to a lower level. As a small matter of distinction, the SC
does not require an "explanation". It requires that the error is
"described" to the user, that she be able to understand it. An
"explanation" is a "detailed description". The SC is not requiring a
detailed description, but simply a description of the error, which is
not as rigorous as an "explanation of the error".
The intent section says:
"The intent of this success criterion is to ensure that users are aware
that an error has occurred and can determine what is wrong."
The working group believes it is reasonable to require a description of
the error at Level One, such as "error: use only numbers" for a
telephone field that was filled with letters, rather than "an error has
occurred" which could be confusing. A description will be necessary at
Level One, for many people with disabilities including those with
cognitive disabilities.
This success criterion does not prevent the use of programmatic
information which can be used by AT or the user agent to identify and
provide error information. There must be some mechanism to provide the
error information to the user with all technologies in use today and the
requirement for text guarantees that. Even when provided by the AT or
user agent rather than the content author, the information can still be
conveyed in some form of text to meet this requirement. Thus, we don't
see the requirement for text as being too restrictive.
*Related Issues:*
*Assigned To:* David MacDonald
*Last Edited:* 2006-10-16 15:21:16
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/979>*
------------------------------------------------------------------------
*Comment LC-1057*
*Sort Terms:* Errors Cognitive
*Document:* WCAG 2.0 Guidelines
*Submitter:* Gian Sampson-Wild <gian@tkh.com.au>
*Comment Type:* general comment
*Location:* minimize-error
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error>
*Comment:*
2.5: There should be a Level 1 SC which requires error prevention
techniques, such as providing instructions at the beginning of a form
Proposed Change:
Create a new SC. I am happy to help with this
*Status:* open
*Working Group Notes:* [TEAMC] [HOLD]
Requiring instructions on forms is a design change to the visual layout
of Web content which doesn't meet our criteria for Level 1.
Alternative 1:
We could add a Level 2 SC but it would have to be general, something
like "A mechanism is provided to help users prevent making errors." We
tried in vain to create more specific success criteria. Remember all the
discussions about our choice of 75 in this 2.5 Level 3 Success Criteria
from 2004: "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."
Sufficient techniques in support of this SC could be:
- Providing instructions at the beginning of forms
- Providing a list of selectable choices
- Providing examples of expected format
I still think this might be too much to require at Level 2. What if the
form is really simple? So we could add a Level 3 success criteria but I
don't think that would satisfy Gian.
It does seem kind of odd that we have a guideline that says "Help users
avoid mistakes... " yet we have nothing at level 1 or 2 to meet it.
Alternative 2:
Maybe we should instead propose rewriting this guideline to "Make it
easy for users to correct mistakes."
Discussed in the 14 September 2006 telecon:
resolution: Return 1057 to team C. Put the results of the survey into
the issue; draft a proposal based on the survey results; also tag the
issue as "cognitive" and put on hold.
Survey Comments:
http://www.w3.org/2002/09/wbs/35422/20060914-teamc/results#x1057
http://www.w3.org/WAI/GL/2006/09/14-wai-wcag-minutes.html
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Andi Snow-Weaver
*Last Edited:* 2006-09-14 20:53:03
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1057>*
------------------------------------------------------------------------
*Comment LC-1118*
*Sort Terms:* Errors
*Document:* Understanding WCAG 2.0
*Submitter:* Gian Sampson-Wild <gian@tkh.com.au>
*Comment Type:* substantive
*Location:* minimize-error-suggestions
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/#minimize-error-suggestions> (Examples)
*Comment:*
Examples: The two examples should be moved to Advisory Techniques
*Status:* open
*Working Group Notes:* [TEAMC] []
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-09-14 05:17:05
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/understandingwcag20/1118>*
------------------------------------------------------------------------
*Comment LC-1119*
*Sort Terms:* Errors
*Document:* Understanding WCAG 2.0
*Submitter:* Gian Sampson-Wild <gian@tkh.com.au>
*Comment Type:* substantive
*Location:* minimize-error-reversible
<http://www.w3.org/TR/UNDERSTANDING-WCAG20/#minimize-error-reversible>
*Comment:*
Is this SC about providing corrections to field errors or highlighting
field errors. The techniques and examples seem contradictory
Proposed Change:
Clarify the techniques and examples
*Status:* open
*Working Group Notes:* [TEAMC] []
Sent email asking for clarification as, to me, it seems that the
examples all discuss providing correction information (except perhaps
the one about mandatory fields - but in that case the correction
information is that it must be completed).
Hi, Gian,
You made the following comment about 2.5.2:
Comment:
Is this SC about providing corrections to field errors or highlighting
field errors. The techniques and examples seem contradictory
Proposed Change:
Clarify the techniques and examples
I'm not exactly sure what you mean. The techniques all discuss providing
a text message to help correct the error. So, the idea is to notify of
the error and provide correction suggestions, if possible. The examples
also provide suggestions for correcting the error. Some of the proposed
advisory techniques may include error detection and highlighting but
they still seem to focus on providing corrections. Can you give me some
more details of how you think this contradict so I can try to address
your comment?
thanks,
-becky
response from Gian:
Firstly I noticed that the phrase "text message" has been used in this
SC as well. I lodged a comment on this previously which I think you
contacted me about. I hope you will be changing the phrase "text
message" to a clearer phrase, throughout the document.
As for the comment, I would argue that indicating a field is mandatory
is not a suggestion for correction. It is highlighting the fact that
there is an error, but not providing any suggestions for correction. It
is a worthy technique, but one that needs to be used in conjunction with
another technique that actually provides a suggested correction as well.
I would argue that Situation A, B and C are all highlighting that an
error has occurred, not actually providing suggestions for correction.
It is the Additional Techniques that actually address the SC. The second
example also addresses the SC.
Cheers,
Gian
Note that "text message" has been changed to "text description"
throughout the guidelines in the editor's draft.
I can understand the situation A is NOT about providing suggestions for
correcting errors. But, it is correcting the error of an empty required
field. Not all fields have a suggested correction - for example, how do
I provide a suggested correction for a First Name field - only the user
can enter the correct value. The techniques for situation B and C do
provide suggestions for correcting the error. Although, these are fairly
generic suggestions, it does explain that suggestions for correction are
provided in text. Do we need more specific examples?
Do we want to remove situation A and that technique? If so, where does
it fit? OR,can we use this future technique for situation A: When
mandatory information has not been provided, including descriptions or
examples of correct information in addition to identifying the field as
mandatory (future link)?
I think that Situations B & C do provide enough general information
about providing suggestions for correction. The SC does specify that the
error has alread occurred and these techniques do provide general
information about providing suggestions for correction. Also, I think
many of the future techniques for correcting suggestions are sufficient
rather than advisory - perhaps we can move some of these into the
sufficient category?
These seem to be sufficient:
*Providing a text description that contains information about the number
of input errors, suggestions for corrections to each item, and
instructions on how to proceed (future link)
*Providing a text description that contains suggestions for correction
as the first item (or one of the first items) of content, or emphasizing
this information in the content (future link)
*Displaying errors and suggestions in the context of the original form
(for example, re-displaying a form where input errors and suggestions
for correction are highlighted and displayed in the context of the
original form) (future link)
*Resolution Working Notes - Unapproved:*
*Related Issues:*
1057 <http://trace.wisc.edu/bugzilla_wcag/show_bug.cgi?id=1057>
*Assigned To:* Becky Gibson
*Last Edited:* 2006-09-14 05:17:08
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/understandingwcag20/1119>*
------------------------------------------------------------------------
*Comment LC-1171*
*Sort Terms:* Errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* Greg Lowney
<gcl-0039@access-research.org> *Affiliation:* Lowney Access
Research, LLC
*Comment Type:* substantive
*Location:* minimize-error-reversible
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error-reversible>
*Comment:*
2.5 3 requires, for Double-A, that methods are provided to help avoid or
undo errors, but only for a certain narrowly-defined set of
interactions. I would recommend that these steps, or at least UNDO, be
repeated as a level 3 success criterion, but applying to all
interactions rather that just those listed in 2.5.3.
Proposed Change:
Add a new Level 3 success criteria:
2.5.5 For all user actions, at least one of the following is true:
1. Actions are reversible.
2. Actions are checked for input errors before going on to the next step
in the process.
3. The user is able to have the information they entered re-presented to
them so they may review and confirm or correct it before final submission.
*Status:* open
*Working Group Notes:* [TEAMC] []
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-09-14 05:17:20
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1171>*
------------------------------------------------------------------------
*Comment LC-1197*
*Sort Terms:* Errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* Al Gilman <Alfred.S.Gilman@IEEE.org>
*Comment Type:* substantive
*Location:* minimize-error-context-help
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error-context-help> ("for
text input")
*Comment:*
is too narrow
Proposed Change:
"for any input where the possible inputs are more varied than five to
nine well-known choices"
*Status:* open
*Working Group Notes:* [TEAMC] []
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-09-14 05:17:22
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1197>*
------------------------------------------------------------------------
*Comment LC-1252*
*Sort Terms:* Errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* Henny Swan <henny.swan@rnib.org.uk> *Affiliation:*
Royal National Institute of the Blind
*Comment Type:* substantive
*Location:* minimize-error
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error> ( Help users
avoid making mistakes.)
*Comment:*
Comment: Success criteria don't mention having instructions in a page to
help users interact (for example fill in forms). Also makes no mention
of placement of help text (for example at the top of forms rather than
at the foot after the submit button. Unsure if SC 2.5.4 covers this.
Proposed Change:
Add the above in as Success Criteria or clarify the are part of 2.5.4 in
the techniques.
*Status:* open
*Working Group Notes:* [TEAMC] []
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-09-14 05:17:24
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1252>*
------------------------------------------------------------------------
*Comment LC-1294*
*Sort Terms:* Errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* Andrew Arch
<andrew.arch@visionaustralia.org> *Affiliation:* Vision Australia
*Comment Type:* substantive
*Location:* minimize-error
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error>
*Comment:*
Comment: The Guideline says "Help users avoid mistakes ..." - none of
the SC appear to address this aspect. THey all seem to relate to the
second part "... make it easy to correct mistakes that do occur". Surely
recommendations such as linear form design, clear and understanable
labels, placing examples before the form control, providing
instructions, etc, would address the first part.
Proposed Change:
add some SC to address "Help users avoid mistakes"
*Status:* open
*Working Group Notes:* [TEAMC] []
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-09-14 05:17:27
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1294>*
------------------------------------------------------------------------
*Comment LC-1449*
*Sort Terms:* errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* David MacDonald <>
*Comment Type:* substantive
*Location:* minimize-error-identified
<http://www.w3.org/TR/WCAG20/complete.html#minimize-error-identified>
*Comment:*
How to Meet Success Criterion 2.5.1
2.5.1 If an input error is detected, the error is identified and
described to the user in text. (Level 1)
There is no sufficient server side technique. Such as ASP, PHP etc...
I'm guess this is because we don't offer server side techniques on our
site. But it brings up an issue that some people may think server side
techniques are not sufficient because they are not listed. If we don't
add anything to the "How To" document I think we need to make it clear
that there are ways to meet the SC with server side programming and they
are omitted from our Sufficient techniques because we do not do Server
side exampes and not because they are not sufficient.
*Status:* open
*Working Group Notes:* [TEAMC]
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-16 15:17:58
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1449>*
------------------------------------------------------------------------
*Comment LC-1450*
*Sort Terms:* errors
*Document:* WCAG 2.0 Guidelines
*Submitter:* David MacDonald <>
*Comment Type:* substantive
*Location:* consistent-behavior-unpredictable-change
<http://www.w3.org/TR/WCAG20/complete.html#consistent-behavior-unpredictable-change>
*Comment:*
Why is F36 Example 2 a deprecated example.
"Failure Example 2:
This is a deprecated example that submits a form when the user selects
an option from the menu."
I think it is still an issue and it us used all the time.
We could also add to it that Blind users and users with hand tremors can
easily make a mistake on which item on the dropdown menu to choose and
they are taken to the wrong destination before they can correct it.
Therefore the technique can also be linked from 2.5.1. I think. Because
it would also be a failure to that technique.
*Status:* open
*Working Group Notes:* [TEAMC]
*Resolution Working Notes - Unapproved:*
*Related Issues:*
*Assigned To:* Nobody
*Last Edited:* 2006-10-16 15:19:13
*Edit Comment
<http://www.w3.org/2006/02/lc-comments-tracker/35422/wcag20-lc/1450>*
Received on Wednesday, 25 October 2006 20:19:37 UTC