W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2006

Issue summary: Errors

From: Michael Cooper <cooper@w3.org>
Date: Wed, 25 Oct 2006 16:21:00 -0400
Message-ID: <453FC72C.8030403@w3.org>
To: List WAI GL <w3c-wai-gl@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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:47 GMT