Provide labels to describe the purpose of the form control.
Use the <label> element to explicitly associate a form control with a label
Match exactly the for attribute of the label with the id attribute of the form control
Elements that use explicitly associated labels are:
<input type="text">
<input type="checkbox">
<input type="radio">
<input type="file"> (file-select fields)
<input type="password">
<textarea>
<select> (drop-down lists)
Do not use the <label> element for the following elements.
Submit and Reset buttons (<input type="submit"> or <input type="reset">)
Label provided by the value attribute
Image buttons (<input type="image">)
Label provided by the alt attribute
Hidden input fields (<input type="hidden">)
Buttons (button elements or <input type="button">)
Label provided by the element content itself (button) or the value, aria-label, or aria-labelledby attribute
Use ARIA labels (aria-labelledby or aria-label attributes) when it is not possible to use <label>
When using ARIA labels, include any visible text in the control label.
Use the aria-labelledby attribute to retrieve a label from the context or to concatenate a label out of one or more elements in the context.
Avoid using the title attribute to identify form controls. It is not widely supported by AT.
Keep label text short and concise.
Use unique label text on a page.
Position labels visually to the right of radio buttons and checkboxes.
Position labels visually directly above their form fields (preferred by WET) or to the left, aligned right (WET alternative, when there’s a need to conserve vertical space).
Grouping controls
Use the <fieldset> element to group related controls in a form.
Use the <legend> element to name the <fieldset> element
Make the legend as short as possible as some assistive technology declares the legend together with the label every time.
Make the individual labels self-explanatory as some assistive technology does not declare the <legend>. Do not repeat the legend in every label.
Use optgroup element for <select> elements with groups of options
Use ARIA role="group" and aria-labelledby attributes to group and label related form elements when you can't use native HTML <fieldset> and <legend> elements.
Use <label> wherever possible for universal browser and screen reader support.
Form instruction
Provide overall instructions that apply to the entire form and provide them before the <form> element. This ensures screen reader users encounter the information before switching to “Forms Mode.”
Use aria-labelledby or aria-describedby to provide instructions outside of labels.
Identify the type of form input field (e.g., type= "email") so that browsers and assistive technology can provide input helpers, such as custom keyboards, autofill and icon labels.
Indicate any required input, data formats, and other relevant information.
Ensure placeholder attribute text meets a minimum contrast ratio of 4.5:1.
Validating input
Validate user data using validation attributes on HTML5 form elements.
Common validation attributes include required, type, pattern, min and max attributes.
Validate data on client-side and server-side to ensure security.
Identify required form fields both visually in the label and semantically.
Use HTML5 input types to validate different types of data, including email, URL, number, telephone, date and range.
Validate patterned input using the pattern attribute to specify a regular expression for matching
Validate length of entries using minlength, maxlength, min and max attributes
Be accommodating as possible of different input formats
Enable your users to check and correct their input to reduce errors.
Require user confirmation for irreversible actions.
Provide undo functionality to ensure submissions are reversible.
User notifications
Upon form submission, notify the user of success or of any errors.
Ensure error messages are clear and concise and provide simple instructions for resolving the error.
Provide feedback in the main heading, in the title element, as a list of errors before the form, as well as in-line, programmatically associated with the form control.
Errors listed before the form should:
Reference the label of the corresponding form control.
Provide a concise, easy to understand description of the error.
Indicate how to correct mistakes, and remind users of any format requirements;
Include an in-page link to the corresponding form control for easy access.
Multi-step forms
Split the form up according to its logical groups of controls (e.g., contact information and questionnaire).
Validate the current step before exposing the next.
Label optional steps and enable users to skip them.
Ensure keyboard focus moves smoothly from step to step, backwards and forwards. At a new step, set the focus preferably on the next relevant form element, or relevant heading or container.
Avoid a time limit to fill out the form. If a limit is required, enable the user to adjust or extend it.
If the steps are across pages, repeat overall instructions on every page.
Indicate progress in the form (“Step x of y”).
Custom controls
Whenever possible, use native HTML form elements rather than custom controls.
Model the behaviour after native HTML form elements.
Add appropriate ARIA name, role, and values if necessary.
Communicate updates and state changes via ARIA live messages when they can’t be communicated through HTML or ARIA methods