By the end of this lesson you can
- Design forms that work for screen reader, keyboard and cognitive accessibility.
- Label fields, group questions and describe errors accessibly.
- Avoid common accessibility failures in forms.
The idea
Forms are where accessibility failures most often block people completely. Key requirements:
Labels and instructions
- Every field has a visible label, programmatically linked to it.
- Hints (format, examples) sit between label and field and are linked too.
- Required and optional fields are marked in text, not just with an asterisk colour.
Grouping
Related controls, such as radio buttons or a date of birth split into day, month and year, are grouped with a fieldset and a legend that asks the question.
Errors
- Describe errors in text, next to the field, linked to it.
- Show an error summary at the top on submit, with links to each field, and move focus to it.
- Say how to fix the problem.
Input help
- Use correct input types and autocomplete attributes so browsers and password managers can fill fields.
- Do not ask people to re-enter information they have already given in the same process (WCAG 2.2, 3.3.7).
- Do not require cognitive tests such as remembering passwords or solving puzzles without an alternative (3.3.8).
- Give enough time, or allow time limits to be extended.
Why it matters in real projects
Forms gate access to services: applications, purchases, bookings and sign-ins. An unlabelled field or an inaccessible error can stop a disabled person from completing a task entirely. Accessible forms also reduce errors and drop-off for everyone, which improves conversion and lowers support costs.
A realistic example
A university application form uses placeholders instead of labels, asterisks in red for required fields, a custom date picker that does not work by keyboard and errors shown only as red borders. A blind applicant using a screen reader cannot tell which fields are which.
The redesign adds visible labels and hints, "(optional)" text, a day/month/year date input grouped with a legend, autocomplete on name and address fields, and an error summary that receives focus. The applicant can now complete it independently.
Step by step
Check labels
Ensure every field has a visible, linked label.
Group related controls
Use fieldset and legend for radio groups and multi-part inputs.
Add hints
Add format hints linked to fields.
Design errors
Inline messages plus a linked summary.
Add autocomplete
Annotate autocomplete values for personal data fields.
Test
Complete the form with keyboard and screen reader.
Common mistakes
Mistake Placeholders as labels.
Instead Use visible labels.
Mistake Radio buttons without a group question.
Instead Use fieldset and legend.
Mistake Errors only in colour.
Instead Add text messages linked to fields.
Check your understanding
Choose an answer, then check it. There is an explanation either way.
Practice exercise
Exercise · about 1 h
Accessible form spec
Make a contact form fully accessible.
Steps
- Design labels, hints and groups.
- Design inline errors and an error summary.
- Annotate autocomplete values.
- Test with keyboard and a screen reader.
Deliverable
An annotated accessible form design with test notes.
Self-assessment
Tick each item when it is true of your exercise. Be honest; this is for you.
4 items
Summary
- Label every field visibly.
- Group related controls with legends.
- Describe errors in text with a summary.
- Use autocomplete and avoid cognitive tests.
Further reading
Third-party sources, chosen for reliability. They open in a new tab.
Your notes
Marking complete updates your course and roadmap progress.