An error should identify the problem, explain a repair, and preserve valid work.
By the end: compare generic failure feedback with a focused summary and associated field messages.
Distinguish field errors from service failures
A missing name, a malformed address, and insufficient capacity are different problems. Tell the person what they can change. A service outage is not a field error, and asking someone to repeatedly retype correct information will not repair it.
The example's capacity is fixed at three. In a real booking service, another person can take the last place between display and submission. A server rejection must return a useful state and preserve the rest of the form, even when the earlier client check passed.
Locate the rule that rejected the value
Imagine asking for four workshop places when the form says three are available. The rejection has a specific cause. The name and email may already be acceptable, so asking the guest to check everything creates needless uncertainty. A useful explanation connects the attempted value to the violated rule and a possible next action. Here the guest can choose fewer seats. In a real service they might instead need another session, but this example has no alternative-session control inside the form.
Separate a missing answer from an answer outside an allowed set. An empty Seats field gives the system no choice to evaluate. The string 4 expresses a choice, but the validator rejects it. This demonstration gives both cases the same instruction because the repair is the same: enter exactly 1, 2, or 3. Different messages would be justified if they led to different repairs. More detailed wording is useful only when it helps the person decide what to change.
A rejected choice needs an actionable rule
Incomplete explanation, static example
Clay basics · 3 places available
Seats entered: 4
Invalid input.
Actual repair wording, static example
Clay basics · 3 places available
Seats entered: 4
Choose 1, 2, or 3 seats. Only three are available.
These static text specimens keep the attempted value and capacity equal. The revised wording supplies the accepted choices; a statement about size alone would not explain why 02 is also rejected by this exact-string validator.
The seat input looks like an ordinary text field and requests a numeric keyboard where supported. That keyboard request is not enforcement. The accepted strings are exactly 1, 2, and 3. A value such as 02, a fraction, or a digit surrounded by spaces does not become a valid choice through numerical interpretation. This distinction matters when explaining a failure. Saying only that the number must be below four would leave several rejected values sounding acceptable under the stated instruction.
Name handling follows a different rule. The validator removes surrounding whitespace before checking that the name has a length between one and sixty. That length is JavaScript string length, not a careful count of visible letters in every writing system. The editable input also has a sixty-unit maximum. These are bounded demonstration constraints, not a general policy for human names. Do not infer that a name which passes is a verified identity or that a rejected long name is illegitimate.
Email handling supplies another contrast. The custom check requires non-space text on both sides of an at sign and a dot in the domain portion, with at most one hundred string units overall. It does not trim a raw argument. However, the native email input removes leading and trailing ASCII whitespace before its value reaches that check. An internal space survives, so mina @example.invalid fails in the actual form. The message gives an example, not evidence that a mailbox exists. No accepted address receives a message here.
These are raw custom-validator arguments, not deliverability tests or a trace through the email control. The browser strips leading and trailing ASCII whitespace from that control before the change handler reads it. An internal space remains and fails the custom rule.
Before using the model, predict the result for Mina Hart, mina, and 2 seats. Only Email violates these rules. Then predict the result for the valid fictional guest with 4 seats. Only Seats violates them. These predictions give you a way to inspect feedback without treating any red border as sufficient evidence. The useful question is whether the interface identifies the same problem you derived and leaves the already acceptable information available for the next attempt.
Try the interface
Your task: Submit the incomplete-email and over-capacity presets. In the revised form, follow the error-summary link to the field, repair it, and submit again.
Complete and repair a booking form
Studio Desk demonstration. Actions affect this page only, not a real booking, account, or payment.
Reference booking form
Clay basics
Saturday, 14:00 · 3 places available
Selected booking form
Clay basics
Saturday, 14:00 · 3 places available
Draft condition
Stated rule
Guest name
1–60 characters after trimming
Email
Bounded email-like format; no delivery check
Seats
Exactly 1, 2, or 3
Invalid submit
Preserve draft and report a problem
Valid submit
Show a local receipt only
Complete validation rules and outcomes remain embedded offline.
Use fictional details. Presets replace both drafts and reset receipts/errors; editing changes only that form. Validation starts on submit, then reported problems update during correction. The email rule is a bounded teaching format check, not delivery verification. Each successful submission creates only a local display receipt.
Follow one failed attempt through correction
Select Incomplete email above and inspect the two forms before submitting. Both drafts contain the same three values. Neither has yet attempted a reservation, so the initial absence of errors does not mean the validator accepts the email. It means feedback has not been requested through submission. Submit the Selected form. Its summary should identify Email, while the name and seat values remain unchanged. The Reference form is independent and has not silently acquired the Selected form's attempt state.
Follow the Email link in the Selected summary. The link moves keyboard focus to the corresponding input rather than opening another page. You can now type without reconstructing the rest of the draft. This connection matters on a larger form because knowing that an error exists and reaching its location are separate problems. Here the short form makes the distance small, but the mechanism remains inspectable. The field message also stays beside the value instead of requiring a return to the summary.
Replace mina with [email protected]. Once submission has exposed errors, subsequent edits recalculate them. The summary disappears when no problems remain, and the receipt area says the details are ready. That intermediate state is not a successful reservation. You have repaired the draft, but have not submitted the repaired values. Activate Reserve seats again to create the local receipt. This second action distinguishes a valid editable draft from a completed attempt even though this example has no network delay.
Details are ready. Submit to create a local receipt.
Submit again
Same valid draft
Demo receipt: 2 seats for Mina Hart. Nothing sent to [email protected].
This trace uses the Selected form and the incomplete-email preset. The ready state prevents removal of an error from being mistaken for completion of a reservation. No message is sent at the final step.
Now submit the Reference form using its original incomplete email. Its generic failure cannot identify which field needs attention, although its values remain present. Compare the work required to recover, rather than merely counting visible messages. You know the planted problem because you selected the preset. A guest encountering their own mistake would not necessarily know it. The comparison therefore demonstrates available information and navigation, not a measured estimate of how much faster all people would complete the form.
Try Blank draft next. This preset replaces both forms, including any one-sided edits, and clears their receipts and attempted-submission feedback. Submit Selected and inspect the three summary links in field order. Repair Guest name first and observe that the other problems remain. This is partial recovery. The form should neither demand that you re-enter the repaired name nor declare the whole draft complete because one error disappeared. The remaining messages describe the current draft rather than a permanent record of the original failure.
One correction removes one problem
After submitting Blank draft
Check these details
Guest name: Enter a guest name of 1–60 characters.
Email: Enter an email with a name and domain, such as [email protected].
Seats: Choose 1, 2, or 3 seats. Only three are available.
After entering Mina Hart only
Check these details
Email: Enter an email with a name and domain, such as [email protected].
Seats: Choose 1, 2, or 3 seats. Only three are available.
Name retained: Mina Hart
The two static summaries represent successive states of the same blank-draft attempt. Supplying a name does not repair Email or Seats. In the working form each remaining entry links to its corresponding field.
Finally choose Four seats, only three left, submit Selected, and change only Seats to 3. Before submitting again, inspect Guest name and Email to confirm they survived. Then read the receipt after the valid submit. It reports the chosen seats and guest while explicitly saying nothing was sent to the address. A correct local result demonstrates the recovery path under fixed rules. It supplies no evidence about real inventory, delivery, persistence after reload, or another guest competing for the same places.
Place feedback where it can be used
The revised form adds an error summary after submission, moves focus to it, and links each message to its field. Field messages repeat the relevant repair and are associated with the input. The reference shows only a generic failure. Both retain values so the comparison isolates feedback quality.
Timing requires judgment. Errors on every keystroke can interrupt an incomplete but normal entry. Checking after blur can help with some constraints, while a submit-level summary catches problems across a form. These models use submit-first validation, then update reported problems as the person edits.
Separate discovering an error from interrupting an edit
A person typing an address passes through strings that are temporarily incomplete. The first few letters do not yet contain an at sign or domain, but they may be part of a correct intended answer. Reporting failure immediately can confuse unfinished work with a rejected attempt. Submit-first feedback sets a clear initial event: the person asked the form to evaluate the draft. After that event, updating visible problems during correction helps them see whether a proposed repair satisfies the stated rule.
Feedback location answers two different questions. A summary answers which parts of the whole attempt need attention. An inline message answers what is wrong with the value currently beside it. In Selected, both use the same validator's wording, with field names added to summary links. If the summary asked for a valid address while the field demanded a work address, the person would face incompatible instructions. Repeating the same repair at two useful locations is different from presenting two different requirements.
One repair at two useful locations
Summary text specimen
Check these details
Email: Enter an email with a name and domain, such as [email protected].
This static specimen reproduces the repair wording at summary and field level. The working summary adds navigation, while the associated field message supports correction beside the current value. These text examples are not operable controls.
Focus is the keyboard's current interaction target. Moving it to the summary after a failed submission makes the newly revealed result reachable without searching backwards through the page. Following a summary link then moves it to a field. Neither operation is a claim about where the eyes must look. A visible focus outline helps identify the target, but actual reading order and announcements depend on browser and assistive technology behavior. This local example is not a complete audit of those combinations.
Correction needs a different focus policy from submission. While editing Email, type an incomplete replacement, then continue toward the accepted example. The field should keep focus as errors update. If each edit sent focus to the summary, the next keystroke would no longer reach the field. The interface would prevent the action needed to satisfy its own instruction. This failure can occur even when the message text is accurate, which is why reviewing error wording alone cannot establish usable recovery.
Do not assume that every changing message is announced automatically. A live region is a programmatic request for assistive technology to announce updates without moving focus. The Selected summary instead receives focus on failed submit, and field messages are associated with their inputs. The reference's generic failure uses an alert. These are different mechanisms with different interruption risks. Adding alerts everywhere would change the interaction, not simply make the same visual feedback more accessible, and would require separate testing.
Focus follows events, not every error update
Event
Keyboard target afterwards
Feedback change
Failed submission
Error summary
Problems across the draft become visible
Activate Email summary link
Email input
The associated repair is beside the value
Type into Email
Email input
Current problems recalculate
Submit while any problem remains
Error summary
The remaining problems are presented together
The correction keeps the field as the keyboard target even while its associated message changes. Only another failed submit redirects focus to the summary. This is the Selected form's policy, not a claim about all assistive-technology announcements.
A useful manual check follows the entire keyboard sequence. Submit an invalid Selected draft, identify the focused summary, activate its Email link, type the correction, and reach Reserve seats with the keyboard. Check that the outline remains visible and the values remain intact. Repeat a failed submission while another problem remains to see the summary become the target again. Record those observed transitions precisely. They establish more than a screenshot of red fields, but less than successful use with every assistive technology.
Preserve an understandable state
An error must not erase successful entries or leave the primary action permanently disabled without explanation. Keep the problem visible until it is resolved, and update the message when the underlying value changes. Avoid declaring success based only on a button animation.
Do not move focus on every validation keystroke. Move it deliberately after a failed submission when a summary helps orient the user, and let them continue correcting the field. A live region and a focus move are different mechanisms; using both indiscriminately can produce redundant announcements.
Preserve work when the cause is elsewhere
Suppose a real service receives a valid request for three seats, then discovers only two remain. The guest did not necessarily misunderstand the earlier display. Availability may have changed between viewing and submission. The form now needs to explain the new constraint and preserve unrelated answers. This is a worked extension beyond the fixed-capacity lab, not a hidden scenario you can trigger there. The lab always checks against three and cannot demonstrate competing bookings or a server's authority over inventory.
Contrast that case with a service outage. Changing Seats from three to two cannot repair an unavailable booking service. A message blaming the seat field would send the person toward ineffective edits and could destroy confidence in previously correct work. A useful failure state identifies that the submission could not be completed, retains the draft, and offers an appropriate next action based on the real service contract. It must also distinguish a known rejection from an uncertain outcome after a missing response.
The booking service is unavailable. Your request was not accepted. Your details remain here.
No field is blamed for the outage.
These are hypothetical service-response copy examples, not available lab modes. Both preserve the same draft. A reduced capacity can justify changing Seats; an unavailable service cannot be repaired by changing an otherwise acceptable seat count.
Retention includes more than keeping text in memory. A form can preserve values while making them difficult to interpret if the labels disappear, if all fields are marked invalid, or if the message hides the session identity. In the validation lab both sides retain visible labels so feedback can be compared without also changing that feature. That choice holds one important factor equal. It does not imply that generic feedback becomes adequate whenever the surrounding form has persistent field names.
Success also changes after an edit. Submit the valid fictional preset in Selected, then change Seats to another valid choice. The previous receipt disappears because it no longer describes a completed attempt for the current draft. The form returns to a ready state until you submit again. Otherwise it could show two seats in the editor alongside a receipt for an earlier choice and leave you uncertain which statement applies. Removing stale success feedback is part of preserving an understandable state.
An edited draft invalidates old success feedback
After valid submit, static result
Seats: 2
Demo receipt: 2 seats for Mina Hart. Nothing sent to [email protected].
After editing Seats, before resubmitting
Seats: 3
Details are ready. Submit to create a local receipt.
The actual form clears its accepted flag on editing. Both seat choices satisfy the rule, but the second has not been submitted. Showing the earlier receipt beside the edited value would confuse draft state with completed-attempt state.
For transfer, consider a fictional newsletter preference form with a display name and a weekly-or-monthly choice. A missing display name is repairable in a field. A disabled mailing service is not. Write one message for each case and specify which values should survive. Then describe what happens after correction but before resubmission. The important intermediate is a ready draft, not an invented success. Use this distinction when reviewing settings screens where editing an accepted value and saving it are separate actions.
When evaluating a proposed repair, ask a person to correct a planted invalid draft without telling them which field is wrong. Observe whether they find the cause, reach the field, preserve correct entries, and recognize the final outcome. Keep this task separate from asking whether the screen looks cleaner. If you change wording, focus, and spacing together, the observation concerns that combined treatment. It cannot identify spacing as the sole cause or establish that local format acceptance guarantees a working booking service.
Exercises
Repair a vague message
The form says "Invalid input" for four requested seats when three remain. Write a useful replacement and describe where it belongs.
Hint
Identify the field, current constraint, and possible correction.
Worked answer
Message part
Purpose
Choose 1, 2, or 3
Actionable correction
Only three available
Reason
Field association
Find the affected input
A message should support recovery.
Use "Choose 1, 2, or 3 seats. Only three are available." Put it near the seat field, associate it programmatically, and include a link from a submission summary. Preserve the name and email. A real concurrent availability response must use the latest accepted capacity.
Avoid aggressive validation focus
While a person edits an email, every keypress moves focus back to the summary. What should change?
Hint
Focus movement is interrupting the repair itself.
Worked answer
Event
Focus policy
Failed submit
Summary may help
Typing a correction
Stay in the field
Following an error link
Move to that field
Feedback and forced navigation are not equivalent.
Keep focus in the field during editing. Update inline feedback without repeatedly redirecting focus. A failed submit can move focus to a useful summary; ordinary corrections should not. Test both keyboard interaction and assistive-technology announcements rather than assuming more alerts are better.
Sources and further reading
Selected guidance and technical definitions were reviewed, not a complete usability literature or accessibility audit. The interfaces are original teaching examples. They do not establish measured improvements in task performance. These optional links are not runtime dependencies.