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]
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.
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 must be:
Mark invalid fields with aria-invalid="true" and pair with aria-errormessage
referencing the error element's id.
Indicate required fields using:
Do not rely on colour alone to indicate required status.
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.
Last edited Apr 5, 2026, 7:17 PM · P**** J****