Inline Validation
Also called field validation, form errors, live validation, field-level errors
Per-field error messages shown during a form rather than only after submitting.
Example
On every keystroke
Type one character and it tells you the address is wrong. It is right, and it is useless — nobody had finished.
When you leave the field
Silent while you type, honest when you leave. Submit with an empty form and focus lands on the first field that needs you.
Both fields carry aria-invalid and point at their message with aria-describedby, so the error is read when focus arrives rather than only seen. Each message states the rule — “Use at least 8 characters” — instead of reporting the failure.
When to use it
- A field has rules the user cannot see — availability, format, length — and finding out at submit costs a round trip.
- The form is long enough that scrolling back to fix things is a real cost.
- The check is cheap and definite: a malformed email, a password too short, a username already taken.
When not to
- The field is trivially self-evident. A required text field with a label needs no live commentary.
- The rule cannot be checked until other fields are filled. Cross-field errors belong at submit, near the fields they relate to.
- The check is slow or costly. A server round trip per keystroke is a bad trade for both of you.
Trade-offs
- Errors are fixed in place, while the field and the intent are still in mind.
- Turns submit from a gamble into a formality.
- Success states can confirm the tricky ones — “Username available” is worth showing.
- Wrong timing makes the form feel hostile: an error appearing mid-word is correcting someone who is still speaking.
- Too many messages at once turns a form into a wall of red, and none of them get read.
- Errors that appear and vanish as the user types cause layout to jump under the cursor.
Accessibility
What this pattern needs in order to work for everyone.
- Keyboard
- Validate on blur, not on every keystroke — but once a field is already in error, re-check as they type so the message clears the moment it is fixed.
- On submit, move focus to the first invalid field. Announcing “3 errors” without taking anyone there is a dead end.
- Never block typing to enforce a format. Filtering keystrokes breaks paste, autofill and every assistive input method.
- Roles and state
- Set `aria-invalid="true"` on the field, and connect the message with `aria-describedby` so it is read when focus lands there.
- Keep the message next to the field and in the accessibility tree — a tooltip-only error is invisible to anyone not hovering.
- An error summary at the top helps on long forms: a list of links, each jumping to its field.
- Do not rely on a red border. The message must say what is wrong, and ideally what would be right.
- Focus
- Focus never moves on its own during typing. It moves once, on submit, to the first field that needs attention.
In the wild
- GOV.UK forms — Errors at submit, with a summary of links at the top and each message repeated above its field.
- Stripe Checkout — Card fields validate on blur, then live once in error, so a corrected number clears the message instantly.