- From: WCAG 2.0 Techniques Submission Form <nobody@w3.org>
- Date: Mon, 01 Feb 2016 18:54:23 +0000
- To: public-wcag2-techs@w3.org
Submitter's Name: Guy Hickling Submitter's Email: guy.hickling@gmail.com Technique ID: UNKNOWN Short Name: Ensuring form fields are not larger than subsequent processing can handle Technique Category: General Techniques Success Criterion Reference: UNKNOWN Applicability: On form input fields and controls Description: The objective of this technique is to ensure that form fields are assigned limits to prevent them accepting more input than can be handled by subsequent processing (including, but not limited to, saving to a database). Otherwise data that the form submission process has accepted without raising an error situation, and which the user thinks has been saved may, in fact, be lost or shortened or otherwise corrupted, all unknown to the user. In the case of text input fields, if the processing of the data subsequent to form submission will only accept a limited length of text input from a field, then that field should be given a maximum input length that is not greater than the maximum length of data that can be processed after form submission. In the case of numeric fields the field should be given minimum and maximum input values that are not outside of the range that can be subsequently processed after form submission. It is true that validation processing can be used to catch any problems later, but it is much better to let the user, especially disabled ones who may find it more difficult to backtrack and amend, know they have reached the limit by preventing further typing (which is what maximum length, min- and max-value attributes are for in most technologies), than to let them carry on typing, maybe extensively, and only tell them later that it was all useless effort. However if the technology in use does not have the facility to set the maximum length of a text field, or the minimum and maximum allowed values of a numeric field, then the author or developer should ensure that: a) the field’s label (or other instructions on the form complying with all other relevant success criteria) includes an instruction such as “not more than NN characters” or “maximum XX “ or “minimum XX and maximum YY”, and b) validate the input (before or after submission) and return the user to the form with an error text message specifying the field concerned and stating what limit has been exceeded and giving the user the opportunity to edit their input data. The form submission process should refuse to accept the form submission until all input data in all fields is within the permitted limits for those fields. Taking these actions ensures that part of the data will not be lost or corrupted due to the form allowing the user to type data, of excessive length or value, into a field that the underlying database, or following processing, cannot handle. It prevents unexpected loss of data. Loss of data in this manner could be serious; it could affect the user’s human rights and well-being if the data is in any way critical from a legal, financial, medical or other similar standpoint. The fact that the data would be lost after form submission would mean that the user would, in all probability, be quite unaware of the loss, and might remain so until some social or legal complication occurred later on. Disabled people are more likely to be harmed than most as some types of disability, such as blindness, impaired sight, or learning disability would make spotting the error at a later date even less likely than for non-disabled people. Reliance should not be placed on errors being raised by the processing after form submision as these may be missed by the user, or not understood, or not be visible, or may not occur depending on the configuration of the subsequent processes. Warnings can be given proactively as the user is typing (especially recommended for entering very long amounts of text), or when the user exits the field to go to the next field, or if not either of those it can be given as an error message after form submission along with the opportunity to correct it (this is the least favourable method as it requires repeating the submission process). Note: It is not always necessary to display limits on screen if they are very obvious and a display would clutter up things unnecessarily, or formatting instructions have already been given, but field input should still be limited or else validation be done to ensure limits are not exceeded. For text fields the error message should state how many characters over limit the input is (preferable), or how many characters are allowed in total. For numeric fields it should state the allowed value limit that has been exceeded. If the user enters a negative value for numeric data that should only be positive, or enters decimal amounts for data that should only be a whole number, then the warning or error message should indicate that. This technique should be used in conjunction with other techniques intended to stop user errors resulting in incorrect data input. Example 1 Head: Ensuring a text input field is no longer in size than its column in the underlying database Example 1 Description: The administrators of a blog site accepting guest posts notice that the titles of some article submissions they receive are cut off mid-word. On investigating they realise that while the title field in the database is only 50 characters long, the title field on the online article entry form has no limit placed on it, so some authors are entering titles without knowing they have gone beyond the available space limit in the database. So the developers amend the web page to place a 50 character limit on that form field, the same as in the database, and they include an instruction in the field’s label, making it, “Article title (maximum 50 characters)”. Example 2 Head: Setting the maximum and minimum attributes on numeric 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. 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 complex 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 permits. 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 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: Steps 5 and 6 will be true - the end character will show in every text field and the correct value in every numeric field. Additional Notes: Most technologies that can create interactive input fields have a facility to limit the number of characters entered (including HTML, Flash, PDF, etc.) in text fields by preventing further typing. Most technologies also allow minimum and maximum limits on a numeric field. If the developer does not use these facilities, user data may be lost. It is too late to ask the user to correct anything at the point when the data is being saved to a database or used in some other processing. And the matter is potentially very serious as it could affect the user’s human rights and well-being if the data is at all critical from a legal, financial or medical standpoint. Sufficiency - This technique will not be sufficient on its own to meet the Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data); it should be combined with (using AND) any one of the existing techniques in Situation A or Situation B or Situation C of that criterion (i.e. G155, G98, G164, G99, G168.) This is because the existing techniques of SC3.3.4 are also not sufficient on their own. They are all intended to avoid the user entering wrong data, but they rely on the user seeing and reviewing the data that is going to be processed whereas, if the author does not set the appropriate field length or value limits on the field inputs, the data the user sees and reviews may not be what will eventually be processed after form submission has been accepted. Applying two techniques together (this new one along with any of the existing techniques for SC3.3.4) will stop both sources of error. For instance, taking each of the techniques under Situation A, G155: Providing a checkbox in addition to a submit button (for the user to say “I confirm the input is correct….”) is insufficient if the user’s input in the form appears to be correct at the time the user ticks the checkbox, but the computer system subsequently loses some of the data on form submission because the field had allowed more input than the subsequent processing can accept. Using this new technique as well as G155 gives full protection to the user. Likewise G98: Providing the ability for the user to review and correct answers before submitting is insufficient because the system, when displaying the data for the user to review, will simply show what was input by the user instead of showing how the data will look after loss or corruption in the post-submission processes. Using this new technique along with G98 ensures what the user reviews will be the same as that which will be saved or used in the post-submission processing. Similarly G164: Providing a stated time within which an online request (or transaction) may be amended or canceled by the user after making the request is not sufficient to adjust the situation because it assumes the user would know an error in subsequent processing has occurred, whereas in fact the error envisaged in this new technique takes place behind the scenes, unknown to the user. The user would expect (indeed has the right to expect) any system to save their input correctly without the need for them to check every data input value individually after the event, so they would not be likely to cancel on account of the system errors. This new technique is needed to ensure that error in subsequent processing does not occur. Similar considerations apply to the techniques in Situations B or C. Reliance should not be placed on later validation because if the developer has forgotten the simple matter of adding the field length attribute then they have probably also forgotten to add validation afterwards. This new technique is necessary as, if the system does not impose limits on field input the user (even sighted ones, and more so blind or sight impaired people or learning disabled ones) is likely to remain quite unaware that part of their input was lost in the processing. I also had a third example for this, if you want to add it in (the submission form only has troom for two): Example 3 - Displaying the number of characters left when the user is typing large amounts of text An online form has a box field asking for the user to type in a message for display on the website. The message will be fed into a system that only accepts 500 characters per message. So the author sets the maximum length attribute on the field to 500 to stop input beyond that number of characters, and also uses client-side scripting to check the message length as each character is typed in, and displays, underneath the box, the number of characters remaining. So users can both check they are within limit at the end (rather than be told they are over limit after form submission and have to edit the message at that stage), and to adjust their input as they go along so as to enter their most important points before they reach the end. 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>Ensuring form fields are not larger than subsequent processing can handle</short-name> <applies-to> <guideline idref="" /> <success-criterion idref="UNKNOWN" /> </applies-to> <applicability> On form input fields and controls </applicability> <ua_issues> </ua_issues> <description> The objective of this technique is to ensure that form fields are assigned limits to prevent them accepting more input than can be handled by subsequent processing (including, but not limited to, saving to a database). Otherwise data that the form submission process has accepted without raising an error situation, and which the user thinks has been saved may, in fact, be lost or shortened or otherwise corrupted, all unknown to the user. In the case of text input fields, if the processing of the data subsequent to form submission will only accept a limited length of text input from a field, then that field should be given a maximum input length that is not greater than the maximum length of data that can be processed after form submission. In the case of numeric fields the field should be given minimum and maximum input values that are not outside of the range that can be subsequently processed after form submission. It is true that validation processing can be used to catch any problems later, but it is much better to let the user, especially disabled ones who may find it more difficult to backtrack and amend, know they have reached the limit by preventing further typing (which is what maximum length, min- and max-value attributes are for in most technologies), than to let them carry on typing, maybe extensively, and only tell them later that it was all useless effort. However if the technology in use does not have the facility to set the maximum length of a text field, or the minimum and maximum allowed values of a numeric field, then the author or developer should ensure that: a) the field’s label (or other instructions on the form complying with all other relevant success criteria) includes an instruction such as “not more than NN characters” or “maximum XX “ or “minimum XX and maximum YY”, and b) validate the input (before or after submission) and return the user to the form with an error text message specifying the field concerned and stating what limit has been exceeded and giving the user the opportunity to edit their input data. The form submission process should refuse to accept the form submission until all input data in all fields is within the permitted limits for those fields. Taking these actions ensures that part of the data will not be lost or corrupted due to the form allowing the user to type data, of excessive length or value, into a field that the underlying database, or following processing, cannot handle. It prevents unexpected loss of data. Loss of data in this manner could be serious; it could affect the user’s human rights and well-being if the data is in any way critical from a legal, financial, medical or other similar standpoint. The fact that the data would be lost after form submission would mean that the user would, in all probability, be quite unaware of the loss, and might remain so until some social or legal complication occurred later on. Disabled people are more likely to be harmed than most as some types of disability, such as blindness, impaired sight, or learning disability would make spotting the error at a later date even less likely than for non-disabled people. Reliance should not be placed on errors being raised by the processing after form submision as these may be missed by the user, or not understood, or not be visible, or may not occur depending on the configuration of the subsequent processes. Warnings can be given proactively as the user is typing (especially recommended for entering very long amounts of text), or when the user exits the field to go to the next field, or if not either of those it can be given as an error message after form submission along with the opportunity to correct it (this is the least favourable method as it requires repeating the submission process). Note: It is not always necessary to display limits on screen if they are very obvious and a display would clutter up things unnecessarily, or formatting instructions have already been given, but field input should still be limited or else validation be done to ensure limits are not exceeded. For text fields the error message should state how many characters over limit the input is (preferable), or how many characters are allowed in total. For numeric fields it should state the allowed value limit that has been exceeded. If the user enters a negative value for numeric data that should only be positive, or enters decimal amounts for data that should only be a whole number, then the warning or error message should indicate that. This technique should be used in conjunction with other techniques intended to stop user errors resulting in incorrect data input. </description> <examples> <ex_head_1> Ensuring a text input field is no longer in size than its column in the underlying database </ex_head_1> <ex_desc_1> The administrators of a blog site accepting guest posts notice that the titles of some article submissions they receive are cut off mid-word. On investigating they realise that while the title field in the database is only 50 characters long, the title field on the online article entry form has no limit placed on it, so some authors are entering titles without knowing they have gone beyond the available space limit in the database. So the developers amend the web page to place a 50 character limit on that form field, the same as in the database, and they include an instruction in the field’s label, making it, “Article title (maximum 50 characters)”. </ex_desc_1> <ex_head_2> Setting the maximum and minimum attributes on numeric 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. 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 complex 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 permits. 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 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> Steps 5 and 6 will be true - the end character will show in every text field and the correct value in every numeric field. </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: Most technologies that can create interactive input fields have a facility to limit the number of characters entered (including HTML, Flash, PDF, etc.) in text fields by preventing further typing. Most technologies also allow minimum and maximum limits on a numeric field. If the developer does not use these facilities, user data may be lost. It is too late to ask the user to correct anything at the point when the data is being saved to a database or used in some other processing. And the matter is potentially very serious as it could affect the user’s human rights and well-being if the data is at all critical from a legal, financial or medical standpoint. Sufficiency - This technique will not be sufficient on its own to meet the Success Criterion 3.3.4 Error Prevention (Legal, Financial, Data); it should be combined with (using AND) any one of the existing techniques in Situation A or Situation B or Situation C of that criterion (i.e. G155, G98, G164, G99, G168.) This is because the existing techniques of SC3.3.4 are also not sufficient on their own. They are all intended to avoid the user entering wrong data, but they rely on the user seeing and reviewing the data that is going to be processed whereas, if the author does not set the appropriate field length or value limits on the field inputs, the data the user sees and reviews may not be what will eventually be processed after form submission has been accepted. Applying two techniques together (this new one along with any of the existing techniques for SC3.3.4) will stop both sources of error. For instance, taking each of the techniques under Situation A, G155: Providing a checkbox in addition to a submit button (for the user to say “I confirm the input is correct….”) is insufficient if the user’s input in the form appears to be correct at the time the user ticks the checkbox, but the computer system subsequently loses some of the data on form submission because the field had allowed more input than the subsequent processing can accept. Using this new technique as well as G155 gives full protection to the user. Likewise G98: Providing the ability for the user to review and correct answers before submitting is insufficient because the system, when displaying the data for the user to review, will simply show what was input by the user instead of showing how the data will look after loss or corruption in the post-submission processes. Using this new technique along with G98 ensures what the user reviews will be the same as that which will be saved or used in the post-submission processing. Similarly G164: Providing a stated time within which an online request (or transaction) may be amended or canceled by the user after making the request is not sufficient to adjust the situation because it assumes the user would know an error in subsequent processing has occurred, whereas in fact the error envisaged in this new technique takes place behind the scenes, unknown to the user. The user would expect (indeed has the right to expect) any system to save their input correctly without the need for them to check every data input value individually after the event, so they would not be likely to cancel on account of the system errors. This new technique is needed to ensure that error in subsequent processing does not occur. Similar considerations apply to the techniques in Situations B or C. Reliance should not be placed on later validation because if the developer has forgotten the simple matter of adding the field length attribute then they have probably also forgotten to add validation afterwards. This new technique is necessary as, if the system does not impose limits on field input the user (even sighted ones, and more so blind or sight impaired people or learning disabled ones) is likely to remain quite unaware that part of their input was lost in the processing. I also had a third example for this, if you want to add it in (the submission form only has troom for two): Example 3 - Displaying the number of characters left when the user is typing large amounts of text An online form has a box field asking for the user to type in a message for display on the website. The message will be fed into a system that only accepts 500 characters per message. So the author sets the maximum length attribute on the field to 500 to stop input beyond that number of characters, and also uses client-side scripting to check the message length as each character is typed in, and displays, underneath the box, the number of characters remaining. So users can both check they are within limit at the end (rather than be told they are over limit after form submission and have to edit the message at that stage), and to adjust their input as they go along so as to enter their most important points before they reach the end.
Received on Monday, 1 February 2016 18:54:31 UTC