A WCAG Technique
I submitted a Technique to the WCAG a few days ago, about a small matter that, though very easy to implement, is often forgotten. HTML4 has long had a "maxlength" attribute on text input fields to specify the maximum length the user is allowed to enter, but it is surprising how often this tiny little item is not added by developers. You can recognise omissions easily enough, when typing into a text field, if you just hold a key down and it just goes on adding more letters without limit.
HTML5 added other input fields, including the number field, and several date and time fields. It gives them the "max" and "min" attributes so the developer can prevent the user entering values outside a permitted range. It also added email, search, password, tel, and url fields that take the same "maxlength" attribute as the simple text field.
Of course, the developer can apply validation for these matters, but if they have forgotten these very simple attributes they probably haven't bothered to validate for these things either! The result, to the user, can be loss or corruption of their carefully typed in data, either when saving to a database or in using it in some other process. On an important data input done for legal, financial, health or other similarly critical matters, the results to the user of the damaged data could potentially be devastating. All for the omission of a single little attribute on an HTML element!
Naturally just having a Technique for it in the WCAG does not necessarily mean all developers will apply it, but at least it improves users' chances of safe input - commercial and public sector websites are increasingly being checked for accessibility, and accessibility audits applied. Disabled people are more vulnerable to this problem as they are less likely to see anything amiss in their data record later than most, so it is a suitable check to add to the WCAG.
So I submitted a new Technique about it, and also a corresponding "Failure Technique" (both links open in a new window) with examples of the fault. They have been submitted under Success Criteria 3.3.4 - "Error Prevention (Legal, Financial, Data)". Don't hold your breath though; I understand it can take W3C a year or two to publish submissions even when they accept them. So it will be interesting to see what happens to this.
The Submitted Technique
The text of the submission (minus the tests) follows. (Sorry for the extremely turgid style, but when creating these things you have to be pretty formal about it, and keep in line with the other documents in the system).
For those familiar with WCAG procedures, I haven't put this forward as a "sufficient" technique. It is intended to be complementary to the existing techniques of Success Criteria 3.3.4:
Ensuring form fields are not larger than subsequent processing can handle
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 submission 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: Ensuring a text input field is no longer in size than its column in the underlying database
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: Setting the maximum and minimum attributes on numeric fields
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.
And My Supporting 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.