Forms should be logically structured, should be keyboard accessible, and should include instructions about requirements and the information being sought.
Associate a label with every form input.
If a label must be hidden, use CSS to visually hide the label, while retaining the markup for screen readers.
Use <fieldset> (with legends) to wrap related form controls together.
Use <optgroup> to visually break up long lists of select options.
If an image is used for a submit button, ensure that a text equivalent is provided.
When a field is required, clearly indicate this inside the label.
Provide informative, apparent and accessible error messages.
Ensure that form help tips and instructions are accessible to screen readers.
In depth
Everyone benefits from well-organized, easy-to-use forms. But it is especially essential for people who use screen readers and screen magnification andwho navigate websites using a keyboard. Without carefully planned and marked up forms, many of these users cannot access online forms.
Labels
Every form input must be associated with a label. There are two ways to associate labels with form inputs:
The first is to provide matching FOR and ID values for each label-input pair:
Although not recommended, if you must hide a label due to design considerations, use a CSS method to visually hide the label, while retaining the markup for screen readers.
NOTE: Screen readers do not read placeholder text, so it should never be a replacement for a label.
Fieldsets and legends
Fieldsets wrap related form controls together. Legends describe the group and should be brief because screen readers repeat them for every field control.
If an image is used for a submit button, ensure that an equivalent text alternative is provided in the markup. Don't use Reset buttons because they are often accidentally clicked.
Screen readers usually skip over any text in forms that is not inside a form element. Therefore, include help tips and instructions either at the beginning of the form, inside the form control's label, or in an aria-describedby attribute. (See more on WAI-ARIA.)
Example:
<label for="password">Create a password:</label> <span id="pass-tip">Passwords must be 8-12 characters and can include letters, numbers and symbols.</span> <input id="password" type="password" name="new-password" aria-describedby="pass-tip"><br>
Creating Accessible Forms
How to test
Many users navigate forms using the keyboard. Check that a form is keyboard accessible by ensuring that:
You can move from one form control to the next using the tab key—in order and without skipping any controls.
Select menus open, and options can be selected using the arrow key.
WCAG 2.1 Guideline 1.1.1 Non-text Content: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.
WCAG 2.1 Guideline 1.4.1 Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.
WCAG 2.1 Guideline 3.3.1 — If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.
WCAG 2.1 Guideline 4.1.2 — Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)