- From: John M Slatin <john_slatin@austin.utexas.edu>
- Date: Wed, 25 Oct 2006 16:38:17 -0500
- To: "Michael Cooper" <cooper@w3.org>, "List WAI GL" <w3c-wai-gl@w3.org>
- Message-ID: <6EED8F7006A883459D4818686BCE3B3B03A8F8D2@MAIL01.austin.utexas.edu>
Several of the comments below express concern about the lack of SC that explicitly address error *prevention* as opposed to correction.
I think the problem for us is that many of the best ways to help users avoid making mistakes in the first place have to do with good usability. We've said that general usability issues are outside the scope of WCAG, except where they have direct bearing on accessibility (paraphrase of a sentence in the Intro). We might add something to this effect to the Intent section of Understanding GL 2.5, e.g., Authors are encouraged to implement best practices for designing usable forms," with references to [usability guru of choice, ISO, HFES, etc.] Providing instructions at the beginning of complex forms is also a good idea (advisory technique, as suggested elsewhere in the comments below). And there's an SC requiring that "Headings and labels are descriptive" (SC 2.4.5, revuew versuin). This is also a Level 3 requirement so won't satisfy people who want something at L1.
Hope this helps.
John
"Good design is accessible design"
John Slatin, Director
Accessibility Institute University of Texas at Austin 1 University station Stop G9600
Austin, TX 78712, USA
Phone +1.512.495.4288 Fax +1.512.495.4524 cell +1.512.784.7533
email jslatin@austin.utexas.edu
www.utexas.edu/research/accessibility/
-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Michael Cooper
Sent: Wednesday, October 25, 2006 3:21 PM
To: List WAI GL
Subject: Issue summary: Errors
* Lots of SC about error recovery but none about error prevention (several comments)
* Better supports for error recovery
* Navigate directly to error
* 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
* Good labeling
* Check for errors before moving to next stage
* 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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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> <mailto: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 21:38:44 UTC