skip to content

When a form submission fails with several errors, what should an error summary contain, and how must it connect to the inline errors?

level: middleimportance: must knowfreq 64%

answer

  1. overview first, detail at the field
  2. focus moves after a failed submit
  3. a count in the heading
  4. each entry jumps to its field
  5. same words in both places

basics

~10 s

An error summary lists every error at the top of the form, takes focus after a failed submit, and links each entry to its field, where a matching inline message sits beside the input.

solid answer

~50 s

After a failed submit the user needs two things: an **overview** of what went wrong and **help at each field**. The summary sits at the top of the form, receives focus so it scrolls into view and is read out, states the count ('There are 3 problems with this form'), and lists each error in form order as a link that moves focus to the field in error. The **inline error** sits with that field's label and input, says the same thing in the same words, and is associated with the field so it is announced with it. Both describe the error in text — WCAG 2.2 3.3.1 Error Identification (Level A) requires that, though it does not mandate a summary; colour and icons only reinforce. The summary updates on each resubmit and disappears once nothing is wrong.

code

pseudocode · 15 lines
pseudocode
on submit(form):
  errors = validate(form.fields)          # ordered as the fields appear
  if errors is empty:
    summary.remove()
    proceed(form)
    return
  for each e in errors:
    e.field.showInlineError(e.message)
  summary.heading = pluralise(count(errors), 'problem') + ' with this form'
  summary.items = [ link(text = e.message, target = e.field) for e in errors ]
  summary.renderAtTopOf(form)
  moveFocus(summary)

on activate(item in summary.items):
  moveFocus(item.target)                   # the input itself, not its group

go deeper

for a junior

Recall the two parts, a summary at the top and a message at each field, and that both must describe the error in words rather than by colour.

for a middle

Explain the submit sequence: inline messages, a counted summary in field order, focus to the summary, and entries that move focus to the input.

for a senior

Diagnose forms where screen-reader users never learn a submit failed, and set the system's threshold for short forms and the per-step rule for multi-step flows.

for a principal

Decide how the pattern is enforced across teams, for example built into a shared form container, and how error wording is owned by content design.

## Two jobs, two places When a form with many fields fails validation on submit, a user faces two separate tasks: **find out what is wrong** and **fix each problem where it is**. One component cannot do both well. - An **error summary** is a block at the top of the form (or the step) that lists every current error. It answers 'how many problems, and where?' - An **inline error** is a message attached to one field. It answers 'what is wrong with this value, and how do I fix it?' A summary alone forces users to hunt for each field; inline errors alone leave a user at the bottom of a long form — or a screen-reader user who has heard nothing — unaware that anything failed at all. ## Anatomy of the summary - A **heading** that states the situation and the count: 'There are 3 problems with this form'. - A **list of entries**, one per error, in the same order as the fields appear. - Each entry is a **link or control that moves focus to the field in error** — the input itself, not the surrounding group or the label. - The entry text is the **same message** the inline error shows, or recognisably the same, so users can match them. - Distinct visual treatment, with an icon or border as reinforcement only, never as the sole signal. ## Anatomy of the inline error, as far as this pattern needs it The exact placement of label, helper text and error inside one field belongs to the text-field specification. For the form pattern, two things matter: the inline message sits with its field so it is visible while fixing, and it is **associated** with the field so assistive technology reads it when the field gains focus. ## The connection, step by step 1. The user submits; validation finds errors. 2. Every field in error shows its inline message. 3. The summary renders at the top with a count and one entry per error, in form order. 4. **Focus moves to the summary**, which brings it into view and makes a screen reader read the heading and list. 5. Activating an entry moves focus to its field, where the inline message is announced with the field's name. 6. On the next submit the summary is rebuilt from the current errors; when there are none, it is removed and the form proceeds. ## What the standards require, and what they do not | WCAG 2.2 criterion | Level | What it asks of this pattern | |---|---|---| | 3.3.1 Error Identification | A | The item in error is identified and the error is **described in text**. It does not say whether that text is a summary, inline, or both. | | 3.3.3 Error Suggestion | AA | When a correction is known, suggest it: 'Enter the cash count as a number, for example 250.00', not 'Invalid'. | | 1.4.1 Use of Color | A | A red border is fine as reinforcement, never as the only cue. | | 4.1.3 Status Messages | AA | If the design announces errors **without** moving focus, the announcement must reach assistive technology as a status message. A summary that takes focus is a change of context instead. | The summary-plus-inline combination is therefore a **design-system convention** that satisfies these criteria well for long forms, not a rule the standard spells out. ## Example: the end-of-shift cash-up on a restaurant tablet A server closes a shift on the point-of-sale tablet: counted cash, card tips, voids to explain, a manager's approval. They submit with the cash count left empty, a void missing its reason, and tips typed with a currency symbol the field rejects. With inline errors only, the server — already at the bottom of the form — sees nothing change on screen except the button. With the pattern: the summary appears at the top with 'There are 3 problems', takes focus, and lists 'Enter the counted cash amount', 'Give a reason for the void on table 12', 'Enter tips as a number, without a currency sign'. Tapping the second entry jumps straight to the void reason, where the same message sits under the field. ## Variations to decide in the system - **Very short forms.** With one or two fields, moving focus to the first field in error may be enough; many systems still show the summary for consistency. Write the threshold down. - **Multi-step forms.** Each step shows a summary of its own errors only. - **Native mobile.** The same model applies: an error region at the top that gains accessibility focus, with each item moving focus to its field.

  • Should the error summary take focus, or be announced while focus stays where it was?
    After a submit the user asked for, moving focus to the summary is the common choice: it scrolls into view and a screen reader reads it at once. If a design keeps focus on the submit control instead, the errors must be announced as a status message under WCAG 2.2 4.1.3 Status Messages (Level AA). What fails is a summary that appears silently.
  • Does a two-field form need an error summary at all?
    Often not. With one or two fields the inline error is already near the user's attention; moving focus to the first field in error may be enough. Many systems still show the summary on every form for consistency. Either way the system should state the threshold so teams do not decide form by form.
  • How does the pattern change on the final review step of a multi-step form?
    Errors found at review may belong to earlier steps. Each summary entry then names the step and links to it with the field focused, and after the fix the user returns to the review rather than walking through every later step again.

A good proofreader returns a cover note listing every problem by page, and also writes a margin note at the exact line, in the same words. The cover note tells you how much work there is; the margin note tells you what to change where you stand. Either alone leaves you hunting.

saying these in an interview costs you the question

  • A red border on the field is enough to identify an error.
  • A summary at the top replaces inline messages, so fields need no error text.
  • Summary entries can be plain text; linking them to fields adds nothing.
  • A message like 'Invalid' is fine because the field is highlighted.
  • WCAG 3.3.1 requires an error summary at the top of every form.