Free community resource
WCAG 1.3.1

Forms & Labels

WCAG criteria

Accessible forms ensure that all users — including those using screen readers,
keyboard navigation, or voice input — can understand, complete, and submit form
controls. The most common form accessibility failures involve missing or
incorrectly associated labels.
[1]


Labels

Every form input must have a programmatically associated label. There are
several correct methods:

Explicit label using for/id:
The label element's for attribute must match the input's id exactly.
This is the most robust and widely supported method.
[2]

Implicit label (wrapping):
Wrapping an input inside a label element creates an implicit association.
Works well for checkboxes and radio buttons.

aria-label:
Provides an accessible name directly on the input. Use when no visible
label is possible. The label will not be visible — use sparingly.

aria-labelledby:
References another element's id as the label. Use when the visible label
text is not a label element.


Grouped inputs

Radio buttons and checkboxes that belong to a group must be wrapped in a
fieldset with a legend element describing the group.
[1]

The legend is announced by screen readers before each option in the group,
giving users the context they need. Without it, users hear only "Yes" or "No"
with no indication of what question is being answered.


Error messages

Error messages must be:

  • Descriptive — explain what went wrong and how to fix it, not just "invalid"
  • Programmatically associated — use aria-describedby to link the error to the input
  • Visible — displayed in text, not only colour
  • Timely — shown after the user has had a chance to complete the field

[3]

Mark invalid fields with aria-invalid="true" and pair with aria-errormessage
referencing the error element's id.


Required fields

Indicate required fields using:

  • The HTML required attribute (adds browser validation and aria semantics)
  • aria-required="true" for custom form controls
  • A visible indicator — asterisk (*) with a legend explaining its meaning

Do not rely on colour alone to indicate required status.


Common mistakes

Placeholder as label. Placeholder text disappears on input and has low
contrast by default. It is not a substitute for a label element.

Generic error messages. "Invalid input" tells users nothing. "Please enter
a valid email address in the format name@example.com" is useful.

Missing fieldset/legend for groups. Individual labels on radio buttons are
not sufficient — the group question context is lost without a legend.


References

  1. W3C Web Accessibility Initiative. Understanding Success Criterion 1.3.1: Info and Relationships. https://www.w3.org/WAI/WCAG22/Understanding/info-and-relationships.html
  2. W3C Web Accessibility Initiative. Understanding Success Criterion 1.3.5: Identify Input Purpose. https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html
  3. W3C Web Accessibility Initiative. Understanding Success Criterion 3.3.1: Error Identification. https://www.w3.org/WAI/WCAG22/Understanding/error-identification.html

Last edited Apr 5, 2026, 7:17 PM · P**** J****