UX Patterns Guide
UI + UX Input And Data Entry standard

Inline validation

Render a field-adjacent validation message only when it helps correction, keep the typed value editable, and describe the exact acceptable format or missing requirement.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A single field has a specific correctable problem.
  • The correction can be explained in one short sentence next to the field.

Avoid when

  • The main recovery task is finding several errors across a submitted page.
  • The issue is not tied to one field or cannot be fixed by changing the user's answer.

Problem it prevents

Users need to repair one invalid field while the entered value, label, hint, and correction remain in the same local context.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Inline validation in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

The user is entering structured data into a known form control.

Pattern promise

Render a field-adjacent validation message only when it helps correction, keep the typed value editable, and describe the exact acceptable format or missing requirement.

Required state

Neutral field with label, hint, and no error.

Recovery path

Error text separated from the field it describes.

Access contract

Expose invalid state on the input and connect error text to the field description where possible.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
  • Invalid state uses field-adjacent text and structure, not color alone.
  • Validation appears after blur or submit when it helps correction.
  • User input remains editable and preserved while the error is fixed.
Weak implementation

Vague, hidden, hard to recover from

  • Only a red border with no message.
  • Error message appears far from the field it describes.
  • Showing errors before users type.
  • Focus jumps on every keystroke or validation flicker.
UI guidance
  • Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
  • Connect the inline message visually and programmatically to the same input it describes.
UX guidance
  • Help users correct a specific field without losing or re-entering the value they already typed.
  • Time validation after blur, submit, or another useful checkpoint so normal partial input is not punished.
Implementation contract

What the implementation must handle

States

  • Neutral field with label, hint, and no error.
  • Invalid field with preserved user value and adjacent correction text.
  • Corrected field with the error removed or replaced by a modest success cue.
  • Submitted form where the invalid field remains reachable and editable.

Interaction

  • The message names the field problem and the correction in plain language.
  • The invalid value remains in the input so the user can edit rather than retype it.
  • The input exposes invalid state and its descriptive error text to assistive technology.

Accessibility

  • Expose invalid state on the input and connect error text to the field description where possible.
  • Do not communicate errors by color alone.
  • Keep labels, hints, and error text in a reading order that makes the correction understandable.
  • Users can tab to the field and edit the preserved value normally.

Review

  • Does the message tell users exactly how to fix this field without leaving the field context?
  • Can the user edit the failing value directly from the error state?
Evidence trail

Source-backed claims behind this guidance

Full agent/debug reference

Problem Context

  • The user is entering structured data into a known form control.
  • The system can identify a problem with that exact control and state the correction briefly.

Selection Rules

  • Choose inline validation when one field has a correctable format, missing-value, range, or requirement problem.
  • Show the message after blur, submit, or another meaningful checkpoint instead of flagging ordinary partial input on every keystroke.
  • Use the same field message alongside an error summary when a submitted page has multiple invalid answers.

Required States

  • Neutral field with label, hint, and no error.
  • Invalid field with preserved user value and adjacent correction text.
  • Corrected field with the error removed or replaced by a modest success cue.
  • Submitted form where the invalid field remains reachable and editable.

Interaction Contract

  • The message names the field problem and the correction in plain language.
  • The invalid value remains in the input so the user can edit rather than retype it.
  • The input exposes invalid state and its descriptive error text to assistive technology.

Implementation Checklist

  • Place the error message immediately after the label and hint, or otherwise directly beside the field it describes.
  • Use visible text plus an invalid field treatment; do not rely on color, an icon, or a border alone.
  • Connect the input to both hint and error text with stable IDs where the platform supports it.
  • Keep both passing and failing answers in place when errors are shown.
  • Avoid premature validation while users are still entering a value that may become valid.

Common Generated-UI Mistakes

  • Showing field errors before users have interacted with the control.
  • Using vague labels such as Invalid value instead of naming the required correction.
  • Clearing or replacing the user's value when validation fails.

Critique Questions

  • Does the message tell users exactly how to fix this field without leaving the field context?
  • Can the user edit the failing value directly from the error state?
Accessibility
  • Expose invalid state on the input and connect error text to the field description where possible.
  • Do not communicate errors by color alone.
  • Keep labels, hints, and error text in a reading order that makes the correction understandable.
Keyboard Behavior
  • Users can tab to the field and edit the preserved value normally.
  • Focus should not jump on every validation update.
  • Submitting an invalid short form may keep focus on or return focus to the field needing correction.
Variants
  • On blur validation
  • On submit validation
  • Password requirement checklist
  • Format-specific field error

Verification

Source trail checked:

Saved items