Reviewed September 30, 2026

Accessible forms

A form is accessible when each field has a name, the user can complete it by keyboard, and errors say which field failed and how to fix it. Those duties come from WCAG 2.2 criteria 1.3.1, 3.3.1, 3.3.2, and 4.1.2.

How should labels be associated?

Wrap the label around the control, or set the label’s for attribute to the input’s id. Group related radio buttons and checkboxes with fieldset and legend. The legend is the question (“Contact method”). Each control’s label is the choice (“Email”, “Phone”).

Required fields should say they are required in text, not only with a red asterisk. Color alone is not enough, which is covered on the use of color page. Format hints, such as “MM/DD/YYYY”, belong in text that stays visible, referenced with aria-describedby if they are not part of the label. Do not rely on placeholder text for either the name or the hint. Success criterion 3.3.2 is covered in full on the labels or instructions page. Fields that collect the user’s own name, email, telephone, or address also need a programmatically determined purpose under 1.3.5, usually an HTML autocomplete token. That check is on the identify input purpose page.

What must an error message include?

• Identify the field: “Email must include an @”, not “Invalid input”. Success criterion 3.3.1 (Error Identification, Level A) is covered on the error identification page.
• Keep the message next to the field and reference it with aria-describedby if it is not inside the label.
• If the field is invalid, set aria-invalid="true" so the state is exposed.
• Move focus to the first error, or to a summary that lists every error as a link to the field.
• Do not clear the user’s text when validation fails.
• Success criterion 3.3.3 (Error Suggestion, Level AA) asks for a suggestion when the correction is known, such as a suggested date format. The full answer is on the error suggestion page.

WCAG 2.2 adds 3.3.7 Redundant Entry (Level A): do not ask for the same information twice in the same process unless it is essential to re-enter it, or the user can select the earlier answer. A checkout that asks for the shipping address again as the billing address should offer a control to copy it.

How should keyboard users get through a form?

Tab order follows the visual order. Every control is reachable with the keyboard, and focus is visible. Custom dropdowns need arrow keys, Enter, and Escape, as described in the WAI combobox pattern. A native select element already does this. A custom widget has to rebuild it.

If a session expires, success criterion 2.2.1 requires a way to turn off, adjust, or extend the limit unless the time limit is essential. Warn the user before the data is lost, and let them extend the session without losing what they typed.

What about authentication?

WCAG 2.2 success criterion 3.3.8 (Accessible Authentication, Minimum, Level AA) says a cognitive function test, such as remembering a password or transcribing a puzzle, cannot be the only way to sign in. Allow a password manager to fill the field, or offer another method that does not rely on memory. Do not block paste on password fields. The full answer is on the accessible authentication page. After submit, a success or error message that only appears visually still needs a status announcement under 4.1.3, covered on the status messages page.