As long as there is a visible text that acts as a label field should be marked with the LABEL element. The text of the label must clearly identify which information called for the user in each control.
All LABEL items and, therefore, the texts of the labels shall be visible and cannot be used techniques of concealment using style sheets not to be used an alternative to label the form field as, for example, the title.
If in the design of the page there is no visible text to mark as label element LABEL, then you can use the title attribute of the field to identify what its role.
For example, if used three contiguous fields to request a date (day, month and year) can be used the title attribute to identify each control instead of including a label for each.
For a proper partnership to be made explicit association labels with their respective controls.
The association explicitly takes place at the level of HTML code, indicating an attribute for for the label and an id attribute for the control. Both attributes must be of equal value.
Aid and briefing notes on the use of form should be provided in text format accessible. Therefore, the best way to indicate a required field is to include such information on the label of the field (for example, by adding the words “ compulsory ” or “ mandatory field " ).
However, and as the extensive use has become a standard, a proper and accessible to identify the compulsory fields on a form is used to mark them asterisks. Before will form an explanatory note indicating that the fields with an asterisk are obligatory.
On the label of each required field is placed an asterisk, preferably by the text of the label. This asterisk could mark as an abbreviation whose title sign will be “ mandatory field for example.
When there are in a form more obligatory fields are optional fields can choose between the opposite strategy. In other words, you can indicate at the beginning of the form that all fields are required except where otherwise indicated, in which case will be included in each field a text identifying it as field is optional.
Moreover, regardless of the technique used to validate the form, should be informed of all validation failures that occur. Must be informed before the form and in the form of accessible text to report on the validation failures that exist to ensure that they do not go unnoticed.
Some new types of HTML5 form allows the automatic validation natively in browsers that support HTML5. When is widely supported this may be an alternative for the validation in client. Meanwhile, if used, there should be an alternative to browsers that have not support this feature.
Be informed about all validation errors produced by entering your details in a form so that users are aware that there have been those errors, to determine their cause and to correct them properly.
Thus, if there are validation failures when sending the form to show a notification in the form of text at the beginning of the page and prior to the form to report on the existence of errors that these do not go unnoticed by the user. It is recommended to include this notification of the presence of errors in the title of the page (TITLE) as it is the first information access a screen reader.
The form has to show all previously introduced by the user unless it is information concerning the safety and not be appropriate to show them as, for example, passwords.
Error messages should be as specific as possible to provide information about the nature of incorrect data and on how to fix them:
- It should provide textual descriptions that identify the required fields that have not been completed. For information to be clear and comprehensible to all users be provided in the form of text, considered insufficient to include only brands such as asterisks or indications of color.
- It should provide textual descriptions to indicate the user that has introduced a fact which does not meet the required format or that is not among the allowed values. For example, by introducing a telephone, postal code, date or e-mail or by incorrect use values not permitted as incorrect province, vat non-existent, dates beyond a certain rank (birth in the future), etc. In all cases should describe the nature of the error.
These error descriptions may be included along with the corresponding form, at the same time as part of its label, as a tabular summary list of errors before the form or as a combination of both techniques.
In case of including a list of errors at the beginning of the form it is recommended to provide links to jump directly from an error message to the corresponding field so that users do not have to find them in the form. This is especially useful for users of screen readers.
In addition, it is advisable to underline or visually emphasize where an error has occurred through images, colors, text styles, etc., but always in a complementary manner to the information supplied in plain text format.
When the data entered by the user are incorrect but is referred to a possible correct value then was due to suggest a text with the correction. This provides the correction of errors. Some examples of suggestions can be correction orthographic similar values within a set of possible values (e.g. province name similar to that introduced and that is incorrect), to additional questions to refine data ambiguous or similar to provide alternatives to avoid repetition of values (e.g. indicate usernames alternative to an existing one).
On the contrary, in the case that there is no validation recommended also show a confirmation message indicating that users in your details have been sent correctly.