What the person is doing
The user is entering structured data into a known form control.
Foundation · lesson 5 of 34 · Input And Data Entry
Inline validation
Underlying principle: An input pattern carries a question, an expected answer, and a consequence. Visible labels, suitable controls, tolerant entry, and specific recovery keep that agreement clear.
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.
Study the interaction
Follow the task before choosing the component
An input pattern carries a question, an expected answer, and a consequence. Visible labels, suitable controls, tolerant entry, and specific recovery keep that agreement clear.
What the interface must communicate
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.
Invalid field with preserved user value and adjacent correction text.
What to look for
Can the user edit the failing value directly from the error state?
The message names the field problem and the correction in plain language.
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.
Problem it prevents
The user is entering structured data into a known form control.
Test the behavior
Try strong and weak versions of the interaction
Open the working example, try its controls, and compare the behavior against the decision guidance.
In the lab you can
Launch Inline validation in the lab - 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.
Pattern anatomy
What a strong implementation has to make clear
The user is entering structured data into a known form control.
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.
Invalid field with preserved user value and adjacent correction text.
Error text separated from the field it describes.
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.
- 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
- Error message appears far from the field it describes.
- Showing errors before users type.
- Focus jumps on every keystroke or validation flicker.
- Error text separated from the field it describes.
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
- 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.
- 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.
- Submitting an invalid short form may keep focus on or return focus to the field needing correction.
Review
- Can the user edit the failing value directly from the error state?
Evidence trail
Source-backed claims behind this guidance
GOV.UK Design System Error message component
Government Digital Service - checked
GOV.UK error message guidance places validation messages next to fields, preserves answers, and requires clear correction wording.
GOV.UK Design System Error summary component
Government Digital Service - checked
GOV.UK error summary guidance is used only to distinguish submitted-page summaries from local inline field recovery.
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: