Web develop - Forms
Ensure that the user can effectively complete the forms
Make form fields accessible #
Target: everyone and especially people with visual impairments, cognitive limitations, experiencing attention difficulties and mobile and tablet users.
When: during design and development.
Description:
Each form input must be associated with a label identifying the function of the field, the type of data and the expected format.
This label should be visually close to the field so we can easily mentally link them (especially for people using zoom or software magnifier or even mobile users).
Each label must be set in a label tag, which is associated to the form field with a for attribute, using the id attribute of the form element.
In some cases, it seems unnecessary to associate a label to a form field because his role is obvious (e.g. search field with a magnifying glass button next to it, a checkbox to select a row in a grid). In such case provide at least a title attribute. A hidden label (using accessible hiding) can also be added, which must be associated with the form field.
Note that the title attribute positioned on a form field tag acts as a label just like the aria-label and aria-labelledby attributes (see ARIA attributes that can save you), preferably in this order.
The autocomplete attribute must be present and relevant for all fields listed in 7. Input Purposes for User Interface Components.
Checklist:
For any form element, the label should be visually close to the field it identifies.
Align all labels to the left when the number of characters separating the longest label from the shortest label does not exceed 6 characters & nbsp ;; beyond that, align all the labels on the right.
If relevant, the fields have an autocomplete attribute so that the user can use a list of pre-recorded or auto-complete proposals.
For radio and check box buttons, in addition to the label tag you can use other tags (title, aria-labelledby, aria-label or, in some cases, fieldset and legend).
For required fields, this should be specified in the label using an image, a text symbol (* for example) or text and / or the aria-required property.
Users’ goal:
Not meeting this requirement is a blocking point for all users using speech synthesis. For mobile users and motor deficient it allows to click on the form elements more easily.
For fields with auto-completion, this avoids users input errors.
Do:
Don’t:
Example of an accessible form:
See the example of an accessible form for more details.
Reference WCAG :
Detect, identify errors and suggest corrections #
Target: everyone and particularly people with visual impairments, cognitive limitations, reading or attention difficulties and elderly people.
When: as of design and during development.
Description:
The errors are automatically detected, the user is warned by a page title change, the error of the form field is clearly identified and the error is described with words to the user. If necessary, a correction is suggested.
Finally, the wording of the error messages should be explicit.
For web pages that involve important actions (legal commitment, financial transaction, modification or deletion of important data, response to a test or examination ...), the action must be reversible or go through a confirmation step to verify or correct the entry in case of error.
Checklist:
Identifying the invalid field, as well as displaying a suggestion of correction can be dynamically added to the label tag, but also to the title tag or aria-label and aria-labelledby tags (see ARIA attributes that can save you) depending on the needs.
Users’ goal:
Guide users when errors happen to improve the understanding and help them correct the errors, especially for internet beginners, elderly people and cognitively deficient.
Do:
Don’t:
Example of an accessible form:
See the accessible form example for more details.
Reference WCAG :