Multiple errors need a summary at the top

What it is

When two or more failures exist on one form, nothing global is visible beside the button. A top summary is a list that appears at the start of the form after submit fails: how many errors, which items. It is a map, not a chance to scroll back from the button and hope. One error does not need that map. Without it, people fix the one they can see, submit again, and hit the next. This entry is only about whether the full set is given at the top. It is not whether list items jump to fields, and not whether the list lets you drop the sentence beside each field. Moving focus to the first error, and scrolling the field into view, are locating moves. The summary is a table of contents.

Why it happens

Working memory cannot hold the whole failure set of a form. After submit, people stand at the end: blank ahead, a string of possibly reddened boxes behind. The summary turns “treasure hunt of unknown length” into “three: email, date, attachment,” so people can finish the list before submitting again, instead of using submit as a probe. A second layer is a count that creates a stopping rule. “3 items to fix” tells people when they are done. Without a count, two fixes later they still do not know whether a third sits in a collapsed section or on the next screen. For a single error the list duplicates the in-field message and is cheap. Once errors cross groups, steps, or collapses, the directory outvalues any one local red line. The summary sits at the top because reading starts at the top. Placing it above the button only serves people who just clicked; people who enter mid-page, or readers who start at the heading, miss it.

Studying it

Build the same form with 1, 3, and 7 errors. Compare field-level messages only, a list at the top, and a list above the submit button.

Independent variables: error count, summary position (top of form / above button / none), whether an error sits inside a collapsed section. Dependent variables: rate of first resubmit still failing, scroll distance to find every error, misses inside collapsed sections, subjective certainty that nothing remains.

Lab forms are short; even three errors are all visible, so the summary is underrated. Use long forms that must scroll and that contain collapses. Faster completion in a summary group is not evidence that jumping worked—that is the next item.

Where it stops holding

A wizard step that cannot contain more than one error by design (one field per step) makes a top list an empty shell. When the server returns only the first error, the list cannot be honest; say “further checks not yet returned” rather than pretend completeness. A live-validation summary that pops at the top before submit turns process state into a final verdict. Printed and emailed forms have no interactive top. On a two-field sign-in where both boxes share the viewport, two visible red lines already are the full set; the list’s increment is small.

Applying it

• If more than one item is invalid after submit, insert a list under the form title with a total count and a short field-name-plus-reason line for each.
• Put the list at the reading start, not only above the submit button. If the list is already on the page when it is entered, focus or the reader should start at the list heading.
• Errors inside collapsed sections, other steps, or hidden-but-submitted fields belong in the list, or the count is a lie.
• Verify by creating three errors, one inside a default-collapsed block; after submit the list must show three. Fix the two visible ones and submit again; people must not think they are done. Move the list above the button and walk from the top with a reader; check whether the list is skipped.

Related

• Within the group: H1.06.2 Summary items should jump to the matching field · H1.06.3 A summary cannot replace field-level messages
• Adjacent: H1.05 Error location and focus · E6.04 Global status messages · H3.02 Three elements of error messages
• Search terms: error summary · error list · form validation