Guide to Guideline 2.5 Level 2 Success Criterion 2

Guideline 2.5 - Help users avoid mistakes and make it easy to correct them. [level 2 guideline]

2.5 L2 SC2: If an input error is detected and suggestions for correction are known and can be provided without jeopardizing the security or purpose of the content, the error is identified and the suggestions are provided to the user.

Key Terms and Important Concepts

Content (from Appendix A of the Guidelines) -Information in the delivery unit that is used by the user agent to generate perceivable units. This includes the code and markup that define the structure, presentation, and interaction, as well as text, images, and sounds that convey information to the end-user.
Input Error (proposed for Guidelines glossary) - any information provided by the user that is not accepted by the delivery unit. This includes: (1) information that is required by the delivery unit but omitted by the user, and (2) information that is provided by the user but that falls outside the expected format or content parameters required by the delivery unit. (Thanks - Andi, Sofia, and Michael..)(NOTE: Is "delivery unit" the most appropriate term? Can error checking occur at the "source web program" as well as in the delivery unit?) (NOTE: Should "expected values" be substituted for "content parameters"?)
User (or end-user?) (proposed definition for Guidelines) - an individual? (or entity - human or non-human?) that directly receives information from a delivery unit via the rendering of content on that delivery unit ( or employs (puts to good purpose?) information from that delivery unit?) (my definition), or (someone employing the content of a delivery unit for explicit purpose?), or (someone doing "real work" with a computer, using it as a means rather than an end; someone who pays to use a computer (from point 1 of [1] - this definition seems more general?)

Intent of this success criterion

The intent of this success criterion is to measure the success of content on a delivery unit in providing the characteristics by which an input error is recognizable in an accessible manner to a user, if the existence of an input error is discerned or discovered on a delivery unit. If such an input error is discerned or discovered on a delivery unit, this success criterion also measures that advice as to how to remedy, remove, or counteract the input error is in fact presented to a user of that delivery unit in an accessible manner. Such advice does not interfere with the goals or desired result of the content, and does not endanger or compromise the content in any way.

The user needs this success criterion is intended to address include those needs for accurate and correct input of data in a timely and accessible fashion to a delivery unit, so that the user's objectives or purpose can be satisfied in interacting with a delivery unit, regardless of disability. Also addressed is the need for assurance that work can be accomplished on a site in an error-free and correct manner, with complete and accurate information about interaction with a delivery unit supplied to a user accessibly, regardless of disability, and this success criterion attempts to provide such assurance.

Techniques for Addressing G2.5 L2 SC2

The following combinations of techniques are deemed to be sufficient by the WCAG Working Group for meeting success criterion 2.5 L2SC2.

Instructions: Select the situation following that matches your content. After each situation are the option(s) that are known and documented to be sufficient for that situation. For the technology-specific techniques, see the option for the techniques you are using listed immediately following.

SITUATION A: A rendering of an HTML form that was not successfully submitted (and an image that it uses). It can also be accessed at [2] for the time being. This situation is of an input error that occurred in among other "correct" input and offers additional help for the form field that caused the input error. If there are multiple errors, then a list of such errors is specifically associated with the delivery unit, and after one input error is "handled" as mentioned previously, an internal link (or other accessible access) is provided to the next error on the list for similar "handling", until there are no more errors on the list.

(NOTE: Do all options need to be supported simultaneously for sufficiency for SITUATION A, or are these really options in the sense of the word, in that only one needs to be provided?)

OPTION A.1 - Using a sufficient combination of technology-specific techniques (labeled "A") following, Inform the user that an input error has occurred before presenting the user with other content using a technology-specific technique following (NOTE: What about suggestions for correction for this option?)
OPTION A.2 - Using a sufficient combination of technology-specific techniques (labeled "A") following, do all of:
- provide information about the number of items requiring change, instructions on how to proceed and an itemized list of the requirements for a successful form submission.
- provide this information as the first item (or one of the first items) of content (if this is the area of the preceivable unit accessed by the user after the form submission).
- Emphasize this content.
OPTION A.3 - Using a sufficient number of technology-specific techniques (labelled "A") following, repeat information about each requirement in the context of its particular form field or group. Emphasize this content. (NOTE: Does "information" include error identification and suggestions for correction?)
OPTION A.4 - Using a sufficient number of technology-specific techniques (labelled "A") following, provide a way for the user to skip from each item in the list of requirements to its particular form field or group (?and a way to shift focus back to the summary?) (NOTE: Do "requirements" or "summary" include error identification and suggestions for correction?)
OPTION A.5 - Using a sufficient number of technology-specific techniques (labelled "A") following, provide additional contextual help for the form fields or group requiring change.

SITUATION B: All other situatations other than SITUATION A occur, where one or more input errors are encountered via other means than in SITUATION A, and for each such "other" input error occurrence, the error is identified and suggestions for correction are provided to the user (via "other" means) when such corrections do not compomise the security and purpose of content on the delivery unit.

(NOTE: Are there any specific examples of this situation?)

(NOTE: I reorganized the original constraints per discussion at the WCAG WG 22 September 2005 teleconference, to eliminate "ORs" and keep the "ANDs" - Options B.1 through B.3 are duplicative in the first clauses, but differ in the final clauses)

(Option Bs are based on David MacDonald's work, but reorganized a little - thanks David!)

OPTION B.1 - Using a sufficient number of technology-specific techniques (labelled "B") following, make error messages distinguishable from other text on the delivery unit , provide feedback for user actions, provide error notification as the user enters information, and providing a list of words that resemble but are not identical to a text field entry
OPTION B.2 - Using a sufficient number of technology-specific techniques (labelled "B") following, make error messages distinguishable from other text on the delivery unit , provide feedback for user actions, provide error notification as the user enters information, and show similar search results/matches
OPTION B.3 - Using a sufficient number of technology-specific techniques (labelled "B") following, make error messages distinguishable from other text on the delivery unit , provide feedback for user actions, provide error notification as the user enters information, and provide an in-page link from error message to field with the error (link error messages to error fields)

Technology-Specific Techniques for 2.5 L2 SC2

(NOTE: These techniques may be duplicative between A and B; need to identify which of these techniques specifically address the success criterion)

HTML Techniques:

A HTML 1 - Include notification that an input error has occurred in the title of the page ('title' element) and the heading for the content ('h1' element).
A HTML 2 - Emphasise information about the number of items requiring change and how to proceed ('strong' element). Provide a list of the requirements in a numbered list ('ol' element). Include an image (error icon) to pictorially represent an item requiring attention.
A HTML 3 - Repeat information about each requirement in its context by including an emphasised statement of the requirement ('strong' element) preceeding the input error location. Include an image (error icon) to pictorially represent an item requiring attention.
A HTML 4 - Implement anchor links ('a' element) for the user to skip from each item in the list of requirements to its particular form field or group.
A HTML 5 - Provide additional contextual help for the form fields or group requiring change, or a link to additional information ('a' element).
A HTML 6 - Implement an accesskey at the list of errors to provide an easy way back to the list (NOTE: Use of accesskeys have usability and accessibility problems?)
A HTML 7 - Add a "skip to next error" link at the end of each field in error. (NOTE: Should this be included as part of the "label"? Also, unless scripting is employed this technique might assume that the user corrects the errors in the order presented in the list of errors.)
B HTML 5.1 - Emphasis
B HTML 5.11 - CSS instead of presentational markup
B HTML 5.12 - Use non-deprecated presentational markup
B HTML 5.14 - Color
B HTML 5.15 - Relative size
B HTML 6.1 - Ordered lists
B HTML 6.2 - Abuse of list markup
B HTML 15.1 - Explicit form labels
B HTML 15.2 - Implicit labels for form controls (deprecated)
B HTML 15.3 - Label form controls with the title attribute
B HTML 15.4 - Grouping form controls
B HTML 15.5 - Grouping options of select elements
B HTML 15.6 - Tab order in forms
B HTML 15.7 - Text alternatives for submit buttons
B HTML 15.8 - tabular forms

CSS Techniques:

A CSS 1 - Use color and increased font-weight to provide emphasis of content for:
- information about the number of items requiring change, instructions on how to proceed and an itemised list of the requirements for a successful form submission
- information about each requirement in the context of its particular form field or group
B CSS 5.5 - Creating invisible labels for form elements
B CSS 7.1 - Specifying colors by keyword or hex value
B CSS 7.2 - Specifying colors
B CSS 7.3 - Creating foreground and background contrast
B CSS 7.4 - Specifying foreground and background color
B CSS 8.1 - Specifying fallback fonts
B CSS 8.2 - Specifying font characteristics
B CSS 8.3 - Specifying font-sizes using xx-small to xx-large
B CSS 9.4 - Spacing letters and words
B CSS 9.5 - Changing case
B CSS 9.7 - Underlining, overlining, and blinking

Client-Side Scripting Techniques:

A JavaScript 1 - Use client-side validation to provide contextual help for the form fields requiring change.
B Script 1 -Scripting technique that provides feedback for user actions
B JavaScript 2 - As soon as the user leaves a field the program looks at what was entered. The program compares what was entered to a set of prescribed criteria. If the information provided by the user matches, the user carries on. If there is an error, a notification pops up.