Validation copy must sit next to the field that failed

What it is

Inline validation puts the explanation beside the control that broke the rule, not in a summary at the top of the form or in a dialog after submit. Adjacent is a double bind of space and object: the notice is visually attached to that field and semantically declared as belonging to it. A malformed email is spoken under the email box, not as a page-top “please check the form.” This is field-level rule checking—required, format, conflict—not a whole-page failure, and not the echo of a successful action.

Why it happens

Fixing an error is a locate–understand–edit loop. The farther the notice from the field, the more locating depends on mapping a sentence at the top onto some box in the middle; with many fields that map collapses. Adjacency folds the three steps into one: the eye is still on the box, the reason is already beside it. People also use spatial proximity to assign ownership: red text between two boxes is attributed to whichever is closer or just blurred. If the notice appears outside the viewport—submit at the bottom of a long form, error written at the top—people may not know there was an error, only that the button seemed to do nothing. Adjacency is not visual neatness; it turns the faulty object from something to infer into something already pointed at.

Studying it

Hold the rules constant and compare three presentations: a summary at the top of the form, a dialog after submit, and copy beside the field. The task is to repair every error and submit successfully.

Independent variables: distance between notice and field, how many fields fail at once, whether the field is in the viewport when the error appears. Dependent variables: whether the first repair click hits the right field, time to clear all errors, edits to the wrong neighbor, and whether people say they could not tell what was wrong.

A top summary looks effective in the lab because participants are told to “get the form right” and will hunt for red text. Real submits more often look like a click, a tiny jump, and a sense that nothing happened. Log whether scrolling occurred and whether focus moved to the first error; those explain failures better than completion time alone.

Where it stops holding

Cross-field rules (two passwords that differ, a start date after an end date) cannot sit on one box without misleading. Mark both fields, or treat them as a group, and name the two values being compared. Errors the server can know only at submit (username taken) should still return to that field, not migrate to a top banner just because they arrived late. In a table, adjacency can occlude the next column; a cell icon that expands in place still has to mean “this cell,” not fall back to one message for the whole grid.

Applying it

• Hang each validation message off its control in the structure, and place it inside the block formed by that label and input, not in a shared form header.
• If an error is off-screen at submit, scroll and move focus to the first one; the notice should already be waiting beside that field, not be replaced by a top-level digest.
• Repeat cross-field errors beside every involved field, with the same sentence naming both objects, rather than reddening only one box.
• Verify by covering field labels and asking someone which box a remaining red sentence is about. A wrong box or two boxes means adjacency failed.

Related

• Within the group: E6.03.2 Showing a notice must not jump the layout · E6.03.3 Assistive technology must announce the notice
• Adjacent: E6.13 Inline result presentation · E2.06 Format hints and examples · E6.10 Error and fallback pages
• Search terms: inline validation · field-adjacent error · error proximity