- From: WCAG 2.0 Techniques Submission Form <nobody@w3.org>
- Date: Mon, 28 Jul 2008 20:34:02 +0000 (GMT)
- To: public-wcag2-techs@w3.org
Submitter's Name: Sailesh Panchang Submitter's Email: sailesh.panchang@deque.com Technique ID: UNKNOWN Short Name: Conveying form validation messages and suggestions for correction in text Technique Category: Server-side Scripting Techniques Guideline Reference: minimize-error-identified Success Criterion Reference: UNKNOWN Applicability: Form input data that needs to be subjected to validation. These checks are in addition to client side checks or done when client side scripting is unavailable. UA Issues: None Description: The objective of this technique is to identify via text, fields in a form that do not pass validation. Where appropriate, the error message can also suggest corrective action. Server-side scripting is used too re-display the form (including any previously entered data). Text is used to identify the field(s) with the error; suggestion for correction is also included where appropriate. Text label for the field is altered to indicate that the data in the field needs to be corrected. This is in addition to visual cues (a surrounding border or changing the label’s color or the field’s background color etc.) that might be used to identify fields that failed validation. Note on validation checks: Data submitted via a form is usually subjected to a validation before it is processed further. This ensures integrity of stored data as well as validity and correctness of output results. Validating input data is a vital step in processing transactions in many applications like online shopping, banking, travel reservations, etc. They have financial and legal implications that once committed may not be easily reversed. Most validations perform one or more of the following checks on input data: 1. Format check: to see if data conforms to a particular format applicable to the data. For instance date may be required to be entered in MM/DD/YYYY format in the birth date field but only as MM/YY when entering the credit card validity. 2. Length check: Data may be checked for minimum and maximum length. A postal zip code in the U.S must always be 5 digits; in India the pin code must always be six digits. A description field in a form may accept data of no more than say, 500 characters. 3. Data type check: Input data may contain only alphabets or only numbers or both. Special characters (punctuations, decimal, plus/minus sign etc.) may or may not be allowed for certain fields. Text may be checked for case (upper / lower). For instance, a password field may need to be between 6 and 14 characters in length and have at least one upper case letter, one number and one special character and not have a space. 4. Range or limit check: Numeric data in some fields may need to be within a minimum and maximum limit. Dates may have an upper and lower bound or may be before or after another date like current date. 5. Equality check: data entered may be checked against a database and compared with data stored by the application. This is done to verify the user’s identity or a transaction reference etc. before processing a request. 6. List check: It may be necessary to select an item from a finite list of values. 7. Completeness check: This is a check to ensure that all required fields have been filled in. 8. Compatibility check: Data entered in one field may be checked with values entered / choices indicated elsewhere on the form. For instance, the form may require one to enter exactly 3 names of family members on a health insurance enrolment form if the user has already indicated that he has 3 dependents. Example 1 Head: Error messages Example 1 Description: Registration date must be in MM-DD-YYYY format Email address is invalid – contains space character(s) Message to editor is 574 characters. (Max. size is 500) Enter zipcode – (required field) Related Techniques: SCR18 Test Procedure: 1. Submit a form with invalid / incomplete data. (Ensure that client side scripting is turned off before submitting the form). 2. Verify the identity of the field containing the error with a clear description of why it failed validation is available in text. Expected Result: Verification as per step#2 is positive. Test File 1: 1. Submit a form with invalid / incomplete data. (Ensure that client side scripting is turned off before submitting the form). 2. Verify the identity of the field containing the error with a clear description of why it failed validation is available in text. Verification as per step#2 is positive. Test File 1 Pass/Fail: pass Additional Notes: This is a sufficient technique for 3.3.1, 3.3.2, 3.3.3, 3.3.4. Note to editors: Refer to my public comment about G83, G84, G85 on Jul. 11, 2008 and WG's response on Jul 24 suggesting I send in a technique covering generic validation issues. I strongly believe SCR 18 is such a technique that addresses all types of validation errors. So I have written one that could be covered under server side techniques. The note on validation checks under Description may be repeated / included under client side scripting techniques. G83, G84 and G85 really do not suggest any "general" technique. They suggest client side or server side based solutions. No example 2 header was submitted! No example 2 description was submitted! No resource 1 title submitted! No resource 1 URI submitted! No resource 2 title submitted! No resource 2 URI submitted! No test file 2 was submitted! No test file 2 pass/fail was submitted! ------------------------------------------------ <technique id="UNKNOWN"> <short-name>Conveying form validation messages and suggestions for correction in text </short-name> <applies-to> <guideline idref="minimize-error-identified" /> <success-criterion idref="UNKNOWN" /> </applies-to> <applicability> Form input data that needs to be subjected to validation. These checks are in addition to client side checks or done when client side scripting is unavailable. </applicability> <ua_issues> None </ua_issues> <description> The objective of this technique is to identify via text, fields in a form that do not pass validation. Where appropriate, the error message can also suggest corrective action. Server-side scripting is used too re-display the form (including any previously entered data). Text is used to identify the field(s) with the error; suggestion for correction is also included where appropriate. Text label for the field is altered to indicate that the data in the field needs to be corrected. This is in addition to visual cues (a surrounding border or changing the label’s color or the field’s background color etc.) that might be used to identify fields that failed validation. Note on validation checks: Data submitted via a form is usually subjected to a validation before it is processed further. This ensures integrity of stored data as well as validity and correctness of output results. Validating input data is a vital step in processing transactions in many applications like online shopping, banking, travel reservations, etc. They have financial and legal implications that once committed may not be easily reversed. Most validations perform one or more of the following checks on input data: 1. Format check: to see if data conforms to a particular format applicable to the data. For instance date may be required to be entered in MM/DD/YYYY format in the birth date field but only as MM/YY when entering the credit card validity. 2. Length check: Data may be checked for minimum and maximum length. A postal zip code in the U.S must always be 5 digits; in India the pin code must always be six digits. A description field in a form may accept data of no more than say, 500 characters. 3. Data type check: Input data may contain only alphabets or only numbers or both. Special characters (punctuations, decimal, plus/minus sign etc.) may or may not be allowed for certain fields. Text may be checked for case (upper / lower). For instance, a password field may need to be between 6 and 14 characters in length and have at least one upper case letter, one number and one special character and not have a space. 4. Range or limit check: Numeric data in some fields may need to be within a minimum and maximum limit. Dates may have an upper and lower bound or may be before or after another date like current date. 5. Equality check: data entered may be checked against a database and compared with data stored by the application. This is done to verify the user’s identity or a transaction reference etc. before processing a request. 6. List check: It may be necessary to select an item from a finite list of values. 7. Completeness check: This is a check to ensure that all required fields have been filled in. 8. Compatibility check: Data entered in one field may be checked with values entered / choices indicated elsewhere on the form. For instance, the form may require one to enter exactly 3 names of family members on a health insurance enrolment form if the user has already indicated that he has 3 dependents. </description> <examples> <ex_head_1> Error messages </ex_head_1> <ex_desc_1> Registration date must be in MM-DD-YYYY format Email address is invalid – contains space character(s) Message to editor is 574 characters. (Max. size is 500) Enter zipcode – (required field) </ex_desc_1> <ex_head_2> </ex_head_2> <ex_desc_2> </ex_desc_2> </examples> <resources> <resources_title1> </resources_title1> <resource_uri1> </resource_uri1> <resources_title2> </resources_title2> <resource_uri2> </resource_uri2> </resources> <related_techniques> <related_technique> SCR18 </related_technique> </related_techniques> <tests> <procedure> 1. Submit a form with invalid / incomplete data. (Ensure that client side scripting is turned off before submitting the form). 2. Verify the identity of the field containing the error with a clear description of why it failed validation is available in text. </procedure> <expected_result> Verification as per step#2 is positive. </expected_result> <test_file_1> 1. Submit a form with invalid / incomplete data. (Ensure that client side scripting is turned off before submitting the form). 2. Verify the identity of the field containing the error with a clear description of why it failed validation is available in text. Verification as per step#2 is positive. </test_file_1> <pass_fail_1> pass </pass_fail_1> <test_file_2> </test_file_2> <pass_fail_2> </pass_fail_2> </tests> </technique> Additional Notes: This is a sufficient technique for 3.3.1, 3.3.2, 3.3.3, 3.3.4. Note to editors: Refer to my public comment about G83, G84, G85 on Jul. 11, 2008 and WG's response on Jul 24 suggesting I send in a technique covering generic validation issues. I strongly believe SCR 18 is such a technique that addresses all types of validation errors. So I have written one that could be covered under server side techniques. The note on validation checks under Description may be repeated / included under client side scripting techniques. G83, G84 and G85 really do not suggest any "general" technique. They suggest client side or server side based solutions.
Received on Monday, 28 July 2008 20:34:38 UTC