VOCABULARY / ENTRY
Inline Validation Feedback
inline-validation
Validation feedback shown right next to an input while people fill in a form or immediately after they finish a field: it identifies the error, describes the problem in text, offers a correction when one is known, and may confirm success for complex fields.
Recognizing it
- Feedback appears attached to its field, below or beside it
- Errors are described in text; color and icons are only supplements
- The message disappears as soon as the input is corrected; complex fields may show a success confirmation
Concept boundary
Inline validation only reports whether a single field's input is acceptable. It is not inline editing (changing content in place) and not the whole error-prevention principle (it is one realization of that principle at the form-field level). Timing is the crux: most fields should be validated after the person leaves the field or reaches the expected length, not from the first keystroke; live constraints such as password strength are the exception. Post-submit error summaries and status messages are its neighbors and cannot replace feedback attached to the field.
When to consider it
- Form fields have automatically checkable format or range constraints that people commonly get wrong
- The form has many fields or is long, so batching errors after submit would force people to hunt back and forth
- Complex fields such as card numbers or email addresses benefit from confirming that nothing was mistyped
When to be cautious
- The result depends on the server and cannot be judged reliably while the person is typing
- There are only one or two fields with trivial constraints and a single check on submit is enough
- Security reasons argue against revealing the specific cause, such as not saying whether the account or the password was wrong at sign-in
Tradeoff
Immediate feedback attached to the field lets people fix errors in context, but validation that fires too early interrupts and blames people before they have finished typing; each field type needs its own trigger decision, and the feedback must be perceivable to screen reader users.
Conditional rules · Editorial advice
Related entries
Inline validation is one concrete realization of the error-prevention principle on form fields: it identifies and helps fix problems before submission.
Inline editing changes how content enters an editable state; inline validation reports whether the content is acceptable. They often co-occur but are separate concepts.
A status message reports the outcome of a whole action without binding to a field; field-level errors belong beside the field, and only a submit-failure summary suits a status message as a supplement.
Validation fires when a field loses focus, and a visible focus indicator shows which field was just left, so people can pair the error with its field.
Sources and what they support
Recommends inline validation wherever possible, with an actionable error message below or next to the problem field; in most cases errors should wait until the person has finished and left the field; icons should supplement color for colorblind users; error messages should be explicit, polite, precise, and give constructive advice.
Retrieved: 2026-09-15Premature inline validation tells people their input is wrong before they have had a chance to type it correctly and hurts the overall experience; validation should trigger on leaving the field (onblur) or on reaching the expected length; error messages should disappear the moment a valid value is entered; test participants welcomed positive confirmation such as a checkmark.
Retrieved: 2026-09-15The Level A criterion requires that when an input error is automatically detected, the item in error is identified and the error is described to the user in text; visual cues such as color or highlighting may only supplement, not replace, the text description.
Retrieved: 2026-09-15 · Archived 2026-09-03The Level AA criterion requires that when an input error is automatically detected and suggestions for correction are known, those suggestions are provided, unless doing so would jeopardize the security or purpose of the content.
Retrieved: 2026-09-15 · Archived 2026-09-17Definitions reference these sources. Digital specimens, selection advice, relationships, and recipes are editorial work and have not been validated through user research.
Type extensions and implementation notes
No operable specimen yet; the illustration is editorial. A product must still verify that each field type's trigger timing is appropriate, that screen readers announce the error text after blur, that errors disappear in real time once corrected, and how server-side validation results are mapped back to their fields.
{
"states": [
"neutral",
"validating",
"valid",
"invalid"
],
"a11y": [
"Associate the error text with the field via aria-describedby and mark the field aria-invalid",
"Do not force focus to move on error; after submit, a summary may move focus to the first field in error"
],
"motion": "The error bar may simply appear or fade in; no shake or other emphasis animation; appear instantly when reduced motion is enabled"
}Open the Agent JSON file for this entryThis file repeats every field of this entry verbatim and adds its sources, archive status, and editorial scope.