Pattern model
Parts that must work together
QuestionLabel and hintInputValidationError summarySubmission and recovery
Why this matters
A pattern is not a screenshot. It is a reusable decision model that must preserve intent, state, recovery, and accessibility as layouts change.
Decision framework
Questions to answer before choosing UI
Do we need to ask?
Remove questions that do not change eligibility, fulfillment, safety, or a clearly explained product outcome.
When should validation run?
Validate at a point where feedback is useful. Avoid interrupting early input, and preserve values when submission fails.
How should errors recover?
Name the field and problem, connect the message to the input, move or announce focus intentionally, and provide a specific correction.
Cross-system baseline
End-to-end accessibility
- Use native labels, fieldsets, and legends
- Connect hints and errors programmatically
- Provide an error summary for long or multi-section forms
- Support zoom, reflow, autofill, and software keyboards
- Never remove entered data after an error
Common mistakes
Failure patterns to test
01
Placeholder-only labels
02
Asterisks with no stated meaning
03
Generic invalid-value messages
04
Disabling submit without explaining incomplete work
05
Splitting one natural answer into excessive fields