A summary cannot replace field-level messages
Aliases: inline error required · summary not enough · field-level error
What it is
A top list gives the full set and a jump, but while people fix an item their eyes are on the field, not the top of the page. A field-level message is the reason sitting next to that input, still readable while they edit. A summary cannot replace it. Strip the sentence beside the field, and even a complete list forces people to work from a distant directory mid-fix. This entry is about the division of labor between two layers. It is not whether a list should exist, and not whether list items jump.
Why it happens
Attention during a fix is local. After a jump, working memory holds “this one is wrong.” The detail—one digit short, a format, mismatch with another field—must sit at the fixation point, or people scroll back to the top to reread. A second layer is that editing stale-dates the directory. The list was built on the submit beat. After one item is fixed, that top line still carries the old reason, while the message beside the field can update with the fingers. With only a summary, people treat the stale directory as truth, rewrite an already-correct item, or think they are not done. A screen reader entering a field reads that field’s description and error property; it does not automatically reread the top list. Without a field-level association, the landing announcement is the field name plus “edit box,” and the reason is gone. The summary is a table of contents. Field-level copy is the manual on the bench. They are not a long and short version of the same thing.
Studying it
Build the same multi-error form as summary only, field-level only, and both. The task is to fix every error and submit.
Independent variables: message layer (summary / field-level / both), whether a sentence remains beside the field after a jump, whether the summary updates during correction. Dependent variables: trips back to the top to reread after a jump, correct items made wrong again, whether a reader can retell the reason after landing in the field, missed items before submit.
A lab list kept short and pinned in the viewport underrates “summary only.” Use a long form where the list scrolls away. Faster completion with a summary is not evidence field-level copy can be deleted—that measures the directory, not the bench manual.
Where it stops holding
On a one-field form (wrong password at sign-in) the summary and the field-level message share a viewport; one layer can be quieted, but the reason sentence still belongs next to the input, not only in a banner far from it. Custom controls that cannot take copy beside them (a pick on a canvas) can use an adjacent live region as field-level; that is still not “replaced by a summary.” When the server returns a vague sentence that cannot be attached to a field (“something is wrong with your details”), field-level will be empty. That is a response-model problem; thickening the summary will not fix it.
Applying it
- Keep a current-reason sentence beside every invalid input. The summary line may be shorter; it cannot be the only source.
- While the person edits inside the field, update the field-level message with the value. Do not make the already-stale top line the only way to know whether the fix is enough.
- When a screen reader enters the field, it should hear name plus current error, not assume the top list is still in memory.
- Verify by jumping to the second error, scrolling so the field is centered and the list is off-screen, and asking what is wrong; no answer means field-level failed. Enter only that field with a reader, skipping the list, and confirm the reason is heard. After the value becomes legal, the sentence beside the field goes and the matching top line updates or disappears; the two must not contradict for long.
Related
- Within the group: H1.06.1 Multiple errors need a summary at the top · H1.06.2 Summary items should jump to the matching field
- Adjacent: E6.03 Inline validation · H3.02 Three elements of error messages · H1.04 Timing of live validation
- Search terms:
inline error·error summary·field-level validation