Resources · 32
Design accessible forms and recoverable errors
Guide entry, explain failure and preserve a person’s progress through the task.
· 18 min
What this guide helps achieve
- Limit fields
- Name and guide
- Explain errors
- Test recovery
Quick check
- Does every field have a perceivable name?
- Are expected formats explained before entry?
- Does an error identify its field and possible correction?
- Are valid values retained?
- Can the task finish with keyboard and zoom?
Step-by-step method
- 01
Start from the task
List only data needed to complete it and the steps a person must understand. Remove requests that do not serve the transaction.
Deliverable: minimal form and field rationale.
- 02
Label and group
Connect each control with a visible label, group related choices and place help nearby. Check reading and tab order.
Deliverable: tested structure and labels.
- 03
Prevent mistakes
Offer format examples and state constraints before submission. Do not use color alone to convey that a field is required.
Deliverable: instructions and entry states.
- 04
Explain each failure
After validation, announce a summary, connect each issue to its field and describe how to resolve it. Keep correct values and context.
Deliverable: correctable error scenario.
- 05
Handle outages
Distinguish entry error, business refusal, timeout and server incident. Give a next step without pretending a request succeeded.
Deliverable: messages and recovery per state.
- 06
Test real tasks
Replay success and failure with keyboard, zoom, mobile and appropriate assistance. Measure blockers, fix them and retest.
Deliverable: evidence of task completion.
Management indicators
| Indicator | What it measures | First action |
|---|---|---|
| Completeness | Needed fields with labels and help | Fix ambiguous controls |
| Errors | Failures with explanation and field link | Rewrite messages |
| Recovery | Values retained after correction | Fix state management |
| Task | Journeys completed with keyboard and zoom | Remove barriers |
Common pitfalls
- Using placeholders instead of labels
- Showing only “an error occurred”
- Erasing the whole form after a mistake
- Testing only the happy path with a mouse
Frequently asked questions
Is a placeholder enough?
No. An identifiable label should remain available while a person enters a value.
When should an error appear?
Choose a useful moment and explain cause and remedy without needless interruption.
What if the server fails?
Do not claim success; retain what can be saved and offer understandable recovery.
Official references
Continue exploring
Related analysis
