Draft Guide to Guideline 2.5 Level 2 Success Criterion 2

Introduction

This is a draft Guide Document (informative) to accompany Web Content Accessibility Guidelines (WCAG) 2.0 Guideline 2.5 Level 2 Success Criterion 2 G2.5L2SC2) ("stated success criterion"). The purpose of this document is to help people who are less familiar with the WCAG understand the needs being addressed by the stated success criterion, as well to help individuals gain knowledge of the different techniques that are known and documented that might be used to meet the stated success criterion. The audience for this document is as indicated in the preceding sentence. Addiitonal advisory information that goes beyond what is required by the stated success criterion is also included.

This document has sections in order as follows: (1) name of stated success criterion and guideline it falls under, (2) key terms, (3) intent of this success criterion, (4) "sufficient" technology-independent techniques for the stated success criterion, (5) "sufficient" technology-specific techniques for the stated success criterion, (6) optional (advisory) techniques for the stated success criterion, (7) benefits of this success criterion, (8) examples of the stated success criterion, and (9) related resources for this success criterion. NOTE: An appendix gives some other issues/questions I had when creating this document. Endings and beginnings of all sections in this document are given by indicators throughout the document, to assist in reading and following the document.

End of Introduction-Beginning of Section 1

Section 1: Statement of Guideline/Success Criterion

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.

Ending of Section 1-Beginning of Section 2

Section 2: Key Terms

Ending of Section 2-Beginning of Section 3

Section 3: Intent of this success criterion

The intent of this success criterion is to measure the success of content on a site 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 site. If such an input error is discerned or discovered on a site, this success criterion also measures that advice as to how to remedy, remove, or counteract the input error is in fact presented to the user in an accessible manner, and is "understandable" by a user. 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.

NOTE: Is "understandability" of the suggestions provided included in this success criterion?

NOTE: An "input error" in this sense may be thought of as just a violation of expectations but not necessarily an "error" from the user's perspective. Also there can be bad data that is not detected by the Web site, but that falls out of scope of the guideline, since the guideline only addresses errors the site will report.

NOTE: Users, as mentioned previously, may include those with a wide range of people with disabilities, including: older users, blindness and low vision, deafness and hearing loss, learning difficulties, cognitive limitations, limited movement, speech difficulties, and others. (Do we need a definition for "user" in Guidelines?) (Possible duplication with information in "Benefits", but not sure of best place to put information)

NOTE: Such users may also be accessing a site using many different devices, including a wide variety of assistive technology as follows:. Web browsers, media players, plug-ins, screen readers, screen magnifiers, on-screen and alternative keyboards, single switches, and a wide variety of input and output devices. (Possible duplication with information in "Benefits", but not sure of best place to put information)

NOTE: This is a level 2 success criterion, which means that it is (1) designed to achieve an enhanced level of accessibility through one or both of: markup, scripting, or other technologies that interact with or enable access through user agents, including assistive technologies, or the design of the content and presentation, and (2) can reasonably be applied to all Web resources.

The goal of this success criterion is that of having interface elements (user interface components) of the content to be operable. Thus the effective access and use of Web content is supported for Web authors (those who create Web content), developers who write code, and even policy makers and managers.

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 site, so that the user's objectives or purpose can be satisfied in interacting with a site, regardless of disability. Also addressed is the need for assurance that work can be accomplished on a site in an error-free manner, with complete and accurate information about interaction with a site supplied to a user accessibly, regardless of disability, and this success criterion attempts to provide such assurance.

Such needs for a user may include: (1) identification of an error occurrence only (for example, username/password errors), (2) identification of an error occurrence and where it occurred on a site (for example, omission of required form fields), (3) identification of an error occurrence, where it occurred, and suggestions for correction (for example, incorect input format), and (4) user input review and correction prior to actual input. (thanks to Sofia for these.. ) This success criterion is most oriented to meet needs following (3) previous.

(see also Benefits Section)

Ending of Section 3-Beginning of Section 4

Section 4: Technology-Independent Techniques Sufficient for G2.5 L2 SC2

NOTE: Use of Techniques 1, 2, and 3 together are deemed sufficient for this SC, along with either Technique 4, Technique 5, or Technique 6, as applicable? "sufficient" is meant in the sense that successful accomplishment of these techniques would meet the SC, in the opinion of the WCAG WG? (Based on David MacDonald's work, but reorganized a little - thanks David! Do we need to provide links to the actual techniques in this document?) (Do we need a definition of "sufficient" in the Guidelines?)

End of Section 4-Beginning of Section 5

Section 5: Technology-Specific Techniques for Guideline 2.5 L2 SC2

NOTE: These are included to support the "sufficient" techniques mentioned previously as possible "resources", but I'm not sure as to how many (if any) of these are "sufficient" in and of themselves, or should be included in this section. Perhaps some (or all) of these are "advisory", and perhaps multiple of these need to be included for "sufficiency"? Comments welcome, as no additional technology-specific techniques were "harvested" for this Guideline?

HTML Techniques:

CSS Techniques:

Client-Side Scripting Techniques:

End of Section 5-Beginning of Section 6

Section 6: Optional Techniques (advisory) for 2.5 L2 SC2

NOTE: Techniques following are optional because their successful accomplishment is not deemed "sufficient" to meet the success criterion, but their accomplishment may be considered beneficial to accessibility (NOTE: Are some of these duplicates of techniques previously mentioned? Are some of these in fact technology-specific?)

Additional Technology-Independent Techniques

Additional Technology-Specific Techniques

NOTE: Should there be more techniques in these categories moved from those listed previously in these categories under "sufficiency"?

HTML Techniques

CSS Techniques

End of Section 6-Beginning of Section 7

Section 7: Benefits - How 2.5 L2 SC2 helps people with disabilities

Identifying typing errors helps users who are blind, individuals with motor disabilities who may press keys by mistake, and those with certain types of learning disabilities who have difficulty writing text.

Certain disabilities make it more difficult to operate input devices, resulting in more input errors. For example, individuals with limited motor functions are more likely to make errors when they operate a mouse or a keyboard. Speech recognition systems may find it more difficult to recognize the speech of individuals with speech disabilities. Features that assist in recognizing and correcting errors benefit individuals with these types of disabilities.

End of Section 7-Beginning of Section 8

Section 8: Examples of 2.5 L2 SC2

Example 1: Identifying errors in a form submission.

An airline web site offers a special promotion on discounted flights. The user is asked to complete a simple form that asks for personal information such as name, address, phone number, seating preference and e-mail address. If any of the fields of the form are either not completed or completed incorrectly, the user is warned of the input error. The user is then presented with the same form, all previously and correctly entered information is still available. The user is asked to make corrections to any form field marked with a red arrow or two asterisks. Note: color alone is not used to indicate errors.

Example 2: Username and password errors.

A Web page requires the user to enter both a username and password. If either is incorrect, the user is informed that there was an error but, for security reasons, is not informed as to which field, the username or the password, is in error and suggestions for correcting are not offered.

Example 3: An online test.

A Web site provides an online test for certification in a particular field of study. The test identifies incorrect answers to the user but does not offer suggestions for correcting them. The purpose of the online test is to test the user's knowledge, therefore, providing hints on correct answers would go against the purpose of the Web site.

Example 4: Order confirmation.

A Web retailer offers online shopping for customers. When an order is submitted, the order information, including items ordered, quantity of each ordered, shipping address, and payment method, are displayed allowing the user to inspect the order for correctness. The user can either confirm the order or make changes.

Example 5: A selection list to reduce errors.

A Web retailer offers online shopping for customers interested in fly fishing gear. When the user is asked for his/her country, a pulldown list of countries is offered instead of having the user enter the information by typing. To possibly make things easier, the user is informed that countries are listed in alphabetical order.

Example 6: Search engine features.

A search engine is provided with a variety of search options for different skill levels and preferences. It includes an option to check the spelling of the search terms and offers "best guess" alternatives, query-by-example searches, and similarity searches.

Example 7: Spell checking in feedback forms.

A banking Web site provides a form for customers to submit questions or suggestions. The form user interface includes an optional spell-checking feature for the text input area where the question or suggestion is entered.

Example 8: Expected date format in a form.

In a form, there is a text box for "birthday". Next to this text box is the text "(MM-DD-YYYY)" to indicate the format in which the date should be entered.

End of Section 8-Beginning of Section 9

Section 9: Related Resources for G2.5L2SC2

NOTE: I am still researching this section. I performed a search on topics of "Using search engines accessibly", filling in forms accessibly", and "Web content user error detection and correction", and am investigating responses. Suggestions welcomed on other resources..

End of Section 9-Beginning of Appendix A

Appendix A: Other Issues/Questions I Had in Doing This Exercise