- From: WCAG 2.0 Techniques Submission Form <nobody@w3.org>
- Date: Sun, 07 Feb 2016 20:21:22 +0000
- To: public-wcag2-techs@w3.org
Submitter's Name: Guy Hickling
Submitter's Email: guy.hickling@gmail.com
Technique ID: UNKNOWN
Short Name: Failure of Success Criterion 3.3.4 due to missing or invalid maximum length or minimum/maximum values on form input fields
Technique Category: HTML and XHTML Techniques
Success Criterion Reference: UNKNOWN
Applicability:
Applicable to HTML forms.
This technique relates to:
• Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)
o How to Meet 3.3.4 Error Prevention (Legal, Financial, Data)
o Understanding Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)
Description:
The objective of this failure technique is to identify input fields on an HTML form that, due to missing or invalid attributes in the HTML markup, could cause user input to be lost or corrupted after form submission.
In text input fields this happens when the developer omits to set a maximum length for the field using the "maxlength" attribute of the HTML input element. It can also happen (though it is less common) if the developer sets it to a value that is larger than will be handled by the processing that takes place after the form submission has been accepted (whether that is saving to a database or some other processing). For this purpose "input field" can mean an input field of type "text", or one of several newer input types of HTML5, or a textarea field, or any custom-created input field that might be created without adding the maxlength attribute.
In fields taking a numeric input in digits the same effect can occur if the input equates (after conversion of the text input to a numeric value) to a numeric value that falls outside the range of values that are handled by the processing that will take place after form submission. This happens, for instance, if the input field allows five digits as input, so the user can enter any number up to 99999, but the destination processing only handles numbers up to 65535 (the maximum two byte number, used in many databases for the smallint integer type.) It can also happen if the user inputs a minus value when subsequent processing only handles positive values.
The result of any of these errors is that, if the user enters input beyond the limit of the subsequent processing or database update, then the data will be shortened, or corrupted (in the above numeric case some databases for instance will change input of 99999 and set the value to 65535 instead, and some databases can also be configured to permit that without returning an error) or lost altogether. However, so far as the form submission process is concerned, the text field had no limit on length, or the numeric field had no limits on value, so the input will be accepted. Only later, in subsequent processing, will the data be lost or changed, and usually the user will be completely unaware of that loss or change.
Note: It is unwise to place reliance on subsequent validation; if the author omits the elementary step of setting the maxlength attribute on a text field, or setting maximum and minimum limits on a numeric value, it is highly probable they will also omit suitable validation to catch the invalid input later. (Or client-side validation may be done in JavaScript by a different developer who assumes the basic field length and value limits were correctly included.) In practice this often happens, and the examples below are not unusual.
Potentially allowing data to be lost or corrupted due to any of the above omissions causes a failure of SC3.3.4, Error Prevention (Legal, Financial, Data) which requires that data input be one of:
1. Reversible: Submissions are reversible.
2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
The techniques to handle these requirements involve such things as making input reversible, or giving the user the opportunity to review and/or disagree to continue with the data submission. Whatever the technique, it involves allowing the user to see the data they have actually input and to correct any mistakes. However if the user has entered text that is too long to be processed later, or a numeric value that is outside the range that can be processed, the input they see for checking is not the same as the data that will be actually processed later. Data will be deleted or corrupted by the system but the user will not be told and will remain oblivious to the damage done. Being reversible will not help either, since the user will assume the data was saved correctly.
In the case of a text field, setting the "maxlength" attribute correctly will physically prevent too much text from being entered. Under HTML5 input fields with a type of numeric, date, datetime, or range can have "min" and "max" attributes which physically prevent out of range values being entered. But in the case of a text field used to input numeric values using HTML4 or XHTML the input field cannot be type numeric; then the developer should provide validation of the field to stop out of range values being entered and force the user to amend it to a value that is within the range suitable for the subsequent processing, and refuse to accept submission until the input is in correct form.
Example 1 Head: Omitting the maxlength attribute on text fields
Example 1 Description:
A finance company provides a "Contact Us" form for people to briefly describe their product requirement and ask a representative to contact them. It has a field for the users email address, and a textarea field for a description.
These details are saved to a database on form submission, the database having a 40 character column for the email address, and a 100 character column for the description. The author applied validation to the email address field to ensure valid input format.
The HTML markup for the form was this:
<form action="#">
<label for="email">Name</label>
<input type="text" id="email" name="email">
<label for="descr">Name</label>
<input type="text" id="descr" name="descr">
</form>
The author of the Contact Us page should also have added the following attributes to the two fields:
maxlength="40" and maxlength="100"
to limit input and stop the user typing more data than would be held by the database. Unfortunately the author did not do that, and the email validation (done using a general-purpose library function that checked format) did not include a check on length either. So when a new customer, who had an unusually long email address, wanted to arrange a financial product the sales team emailed him back the same day but, because the users email address was more than 40 characters, the last few characters of the email address were lost on saving to the database. So the stored address was invalid and their return email never arrived. The matter was urgent and the person had to take a product with a different company at a higher price (and the owner of the first website lost the business.)
Example 2 Head: Omitting the min and max attributes on numeric and other fields
Example 2 Description:
An insurance company arranges travel insurance for people between the ages of 25 and 65. Its online quotation system asks a long list of complex questions about health and status, starting with basic details including age (which uses an HTML5 number field). The markup for the age field should be this:
<input type="number" min="25" max="65" id="age" name="age">
But the designer and author do not set limits on the age field because in their personal view the explanation of all the various restrictions has already been sufficiently explained elsewhere on the website. The validation of the data is done on form submission when all questions have been completed. So people wanting quotes frequently fill out all the fields only to be told, at the end, that they are not eligible due to their age. They could have found this out at the start, and be saved the trouble, if the author had just set appropriate maximum and minimum limits on numeric fields.
Test Procedure:
For each field on the page or document:
1. In each text field enter text right up to the end of the field, using a particular character as the end character of each field to identify the end of the input.
2. In each numeric field enter the maximum possible value the form allows.
When all fields are completed:
3. Submit the form.
4. Retrieve the data in whatever way the system provides (or check the database directly).
5. Check each text field contains all the text originally entered into it, including the identifying end character.
6. Check each numeric field contains the exact value originally entered into it.
Note 1: If during Steps 1 and 2 a field is found to allow an excessively longer input than would be reasonable for that data item, seemingly having no limit set, it is probable that the field length has not been set at all (checking the source code may confirm that); in which case that field has already failed this test.
Note 2: Fields that are neither simple text nor numeric should be similarly tested using whatever test inputs are relevant to the type of field.
Expected Result:
If either steps 5 or step 6 are false, i.e. the end character does not show in one or more text fields or one or more numeric fields do not show the correct value, then the form (and therefore the page) has failed the Success Criterion 3.3.4.
Additional Notes:
A General technique has recently been submitted by myself describing the generic situation and methods to use in general terms for all technologies. This Failure Technique now provides failure examples specific to HTML. When the General technique has been allocated a number, that number needs to be added to this failure technique under "Related Techniques".
No guidelines reference was submitted!
No UA issues were 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>Failure of Success Criterion 3.3.4 due to missing or invalid maximum length or minimum/maximum values on form input fields</short-name>
<applies-to>
<guideline idref="" />
<success-criterion idref="UNKNOWN" />
</applies-to>
<applicability>
Applicable to HTML forms.
This technique relates to:
• Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)
o How to Meet 3.3.4 Error Prevention (Legal, Financial, Data)
o Understanding Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data)
</applicability>
<ua_issues>
</ua_issues>
<description>
The objective of this failure technique is to identify input fields on an HTML form that, due to missing or invalid attributes in the HTML markup, could cause user input to be lost or corrupted after form submission.
In text input fields this happens when the developer omits to set a maximum length for the field using the "maxlength" attribute of the HTML input element. It can also happen (though it is less common) if the developer sets it to a value that is larger than will be handled by the processing that takes place after the form submission has been accepted (whether that is saving to a database or some other processing). For this purpose "input field" can mean an input field of type "text", or one of several newer input types of HTML5, or a textarea field, or any custom-created input field that might be created without adding the maxlength attribute.
In fields taking a numeric input in digits the same effect can occur if the input equates (after conversion of the text input to a numeric value) to a numeric value that falls outside the range of values that are handled by the processing that will take place after form submission. This happens, for instance, if the input field allows five digits as input, so the user can enter any number up to 99999, but the destination processing only handles numbers up to 65535 (the maximum two byte number, used in many databases for the smallint integer type.) It can also happen if the user inputs a minus value when subsequent processing only handles positive values.
The result of any of these errors is that, if the user enters input beyond the limit of the subsequent processing or database update, then the data will be shortened, or corrupted (in the above numeric case some databases for instance will change input of 99999 and set the value to 65535 instead, and some databases can also be configured to permit that without returning an error) or lost altogether. However, so far as the form submission process is concerned, the text field had no limit on length, or the numeric field had no limits on value, so the input will be accepted. Only later, in subsequent processing, will the data be lost or changed, and usually the user will be completely unaware of that loss or change.
Note: It is unwise to place reliance on subsequent validation; if the author omits the elementary step of setting the maxlength attribute on a text field, or setting maximum and minimum limits on a numeric value, it is highly probable they will also omit suitable validation to catch the invalid input later. (Or client-side validation may be done in JavaScript by a different developer who assumes the basic field length and value limits were correctly included.) In practice this often happens, and the examples below are not unusual.
Potentially allowing data to be lost or corrupted due to any of the above omissions causes a failure of SC3.3.4, Error Prevention (Legal, Financial, Data) which requires that data input be one of:
1. Reversible: Submissions are reversible.
2. Checked: Data entered by the user is checked for input errors and the user is provided an opportunity to correct them.
3. Confirmed: A mechanism is available for reviewing, confirming, and correcting information before finalizing the submission.
The techniques to handle these requirements involve such things as making input reversible, or giving the user the opportunity to review and/or disagree to continue with the data submission. Whatever the technique, it involves allowing the user to see the data they have actually input and to correct any mistakes. However if the user has entered text that is too long to be processed later, or a numeric value that is outside the range that can be processed, the input they see for checking is not the same as the data that will be actually processed later. Data will be deleted or corrupted by the system but the user will not be told and will remain oblivious to the damage done. Being reversible will not help either, since the user will assume the data was saved correctly.
In the case of a text field, setting the "maxlength" attribute correctly will physically prevent too much text from being entered. Under HTML5 input fields with a type of numeric, date, datetime, or range can have "min" and "max" attributes which physically prevent out of range values being entered. But in the case of a text field used to input numeric values using HTML4 or XHTML the input field cannot be type numeric; then the developer should provide validation of the field to stop out of range values being entered and force the user to amend it to a value that is within the range suitable for the subsequent processing, and refuse to accept submission until the input is in correct form.
</description>
<examples>
<ex_head_1>
Omitting the maxlength attribute on text fields
</ex_head_1>
<ex_desc_1>
A finance company provides a "Contact Us" form for people to briefly describe their product requirement and ask a representative to contact them. It has a field for the users email address, and a textarea field for a description.
These details are saved to a database on form submission, the database having a 40 character column for the email address, and a 100 character column for the description. The author applied validation to the email address field to ensure valid input format.
The HTML markup for the form was this:
<form action="#">
<label for="email">Name</label>
<input type="text" id="email" name="email">
<label for="descr">Name</label>
<input type="text" id="descr" name="descr">
</form>
The author of the Contact Us page should also have added the following attributes to the two fields:
maxlength="40" and maxlength="100"
to limit input and stop the user typing more data than would be held by the database. Unfortunately the author did not do that, and the email validation (done using a general-purpose library function that checked format) did not include a check on length either. So when a new customer, who had an unusually long email address, wanted to arrange a financial product the sales team emailed him back the same day but, because the users email address was more than 40 characters, the last few characters of the email address were lost on saving to the database. So the stored address was invalid and their return email never arrived. The matter was urgent and the person had to take a product with a different company at a higher price (and the owner of the first website lost the business.)
</ex_desc_1>
<ex_head_2>
Omitting the min and max attributes on numeric and other fields
</ex_head_2>
<ex_desc_2>
An insurance company arranges travel insurance for people between the ages of 25 and 65. Its online quotation system asks a long list of complex questions about health and status, starting with basic details including age (which uses an HTML5 number field). The markup for the age field should be this:
<input type="number" min="25" max="65" id="age" name="age">
But the designer and author do not set limits on the age field because in their personal view the explanation of all the various restrictions has already been sufficiently explained elsewhere on the website. The validation of the data is done on form submission when all questions have been completed. So people wanting quotes frequently fill out all the fields only to be told, at the end, that they are not eligible due to their age. They could have found this out at the start, and be saved the trouble, if the author had just set appropriate maximum and minimum limits on numeric fields.
</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>
For each field on the page or document:
1. In each text field enter text right up to the end of the field, using a particular character as the end character of each field to identify the end of the input.
2. In each numeric field enter the maximum possible value the form allows.
When all fields are completed:
3. Submit the form.
4. Retrieve the data in whatever way the system provides (or check the database directly).
5. Check each text field contains all the text originally entered into it, including the identifying end character.
6. Check each numeric field contains the exact value originally entered into it.
Note 1: If during Steps 1 and 2 a field is found to allow an excessively longer input than would be reasonable for that data item, seemingly having no limit set, it is probable that the field length has not been set at all (checking the source code may confirm that); in which case that field has already failed this test.
Note 2: Fields that are neither simple text nor numeric should be similarly tested using whatever test inputs are relevant to the type of field.
</procedure>
<expected_result>
If either steps 5 or step 6 are false, i.e. the end character does not show in one or more text fields or one or more numeric fields do not show the correct value, then the form (and therefore the page) has failed the Success Criterion 3.3.4.
</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:
A General technique has recently been submitted by myself describing the generic situation and methods to use in general terms for all technologies. This Failure Technique now provides failure examples specific to HTML. When the General technique has been allocated a number, that number needs to be added to this failure technique under "Related Techniques".
Received on Sunday, 7 February 2016 20:21:26 UTC