General Techniques - Providing text descriptions to identify validation errors and suggestions for correction upon form submission.

Submitter's Name: Sailesh Panchang
Submitter's Email: sailesh.panchang@deque.com

Technique ID: UNKNOWN
Short Name: Providing text descriptions to identify validation errors and suggestions for correction upon form submission.
Technique Category: General Techniques
Guideline Reference: minimize-error-identified
Success Criterion Reference: UNKNOWN

Applicability:
Form input data that needs to be subjected to validation  

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. 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. 



Client side scripting can be used to present an alert dialog with the error message. Once the alert is dismissed by the user, the script could place the input focus on the field that needs correction. When there are multiple errors, some scripts list the errors at the start or end of the form under a suitable heading like, “** Errors in form- please correct and resubmit”. In either case, the text label for the  field is altered to indicate that the data in the field needs to be corrected. 



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.



Example 1 Head: Sample error messages
Example 1 Description:
1. Registration date must be in MM-DD-YYYY format

2. Email address is invalid – contains space character(s)

3. Message to editor is 574 characters. (Max. size is 500)

4. Enter zipcode – (required field) 



Test Procedure:
1. Submit a form  with invalid / incomplete data. 

2. Verify the identity of the field containing the error with a clear description of why it failed validation is available in text.

===

Repeat steps 1 and 2 above with client side scripting turned off  before submitting the form 

Expected Result:
Verification as per step#2 is positive. 

Additional Notes:
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. These transactions 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. 



===

Note to editors: 



This is a sufficient technique for 3.3.1, 3.3.2, 3.3.3, 3.3.4	

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.  



This is being submitted as a general technique and in my opinion can replace G83, G84, G85 if retained as a general technique. 

Ideally, this technique should be included under server side techniques. 



SCR 18 is a similar technique that addresses all types of validation errors. 





Pardon me if this technique has already been received from me. I never got an email or confirmation after submission a few weeks ago.  

No UA issues were submitted!
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 related techniques were submitted!
No test file 1 was submitted!
No test file 1 pass/fail was submitted!
No test file 2 was submitted!
No test file 2 pass/fail was submitted!


------------------------------------------------

<technique id="UNKNOWN">
<short-name>Providing text descriptions to identify validation errors and suggestions for correction upon form submission.</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  
</applicability>
<ua_issues>

</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. 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. 



Client side scripting can be used to present an alert dialog with the error message. Once the alert is dismissed by the user, the script could place the input focus on the field that needs correction. When there are multiple errors, some scripts list the errors at the start or end of the form under a suitable heading like, “** Errors in form- please correct and resubmit”. In either case, the text label for the  field is altered to indicate that the data in the field needs to be corrected. 



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.


</description>

<examples>
<ex_head_1>
Sample error messages
</ex_head_1>
<ex_desc_1>
1. Registration date must be in MM-DD-YYYY format

2. Email address is invalid – contains space character(s)

3. Message to editor is 574 characters. (Max. size is 500)

4. 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_techniques>

<tests>
<procedure>
1. Submit a form  with invalid / incomplete data. 

2. Verify the identity of the field containing the error with a clear description of why it failed validation is available in text.

===

Repeat steps 1 and 2 above with client side scripting turned off  before submitting the form 
</procedure>
<expected_result>
Verification as per step#2 is positive. 
</expected_result>
<test_file_1>

</test_file_1>
<pass_fail_1>

</pass_fail_1>
<test_file_2>

</test_file_2>
<pass_fail_2>

</pass_fail_2>
</tests>

</technique>

Additional Notes:

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. These transactions 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. 



===

Note to editors: 



This is a sufficient technique for 3.3.1, 3.3.2, 3.3.3, 3.3.4	

Refer to my public comment about G83, G84, G85 on Jul. 11, 2008 and WG&#039;s response on Jul 24 suggesting I send in a technique covering generic validation

issues.  



This is being submitted as a general technique and in my opinion can replace G83, G84, G85 if retained as a general technique. 

Ideally, this technique should be included under server side techniques. 



SCR 18 is a similar technique that addresses all types of validation errors. 





Pardon me if this technique has already been received from me. I never got an email or confirmation after submission a few weeks ago.

Received on Friday, 29 August 2008 20:53:35 UTC