AI-Built Forms: Keep User Input When Submission Fails

Ask a coding agent to test the failed submission before accepting a new form. A person who corrects one field should not have to reconstruct every valid answer. A person whose request may already have arrived should not be told to submit again without a way to resolve that uncertainty. Both are ordinary events, and a form that handles neither has passed only the demo.

The practical acceptance question is whether the user can finish after something goes wrong. The six cases below give the agent a focused recovery test plan; passing the happy path alone does not answer it. This guide sets out the cases and the state each one should leave the user in, what the W3C’s form guidance does and does not require, why a lost response is not a rejection, the fixes that make recovery worse, and the exercise to hand the agent so the evidence is something a reviewer can replay.

A coding agent asked to build a form may build only the path where everything works, test that path, and report success. That is the path it was described. The failures arrive later, from users who typed a space in a phone number, lost signal in a lift, or left the tab open until their session expired. Each of those people is at the exact moment they are most likely to give up, and the form’s behavior in that moment is the product.

So the acceptance test has to be phrased around failure. Not “does the form submit?” but “after each of these six things goes wrong, can the person still finish, and does the record they end up with match what the screen told them?” Phrased that way, the agent can build toward it and a reviewer can replay it. Phrased as “good error handling”, neither can.

Run these cases in an authorized test environment using identifiable test data. The expected states are design recommendations; adapt them to the form’s sensitivity and destination semantics. A case is not passed until the user can proceed and the destination agrees with the message, which means every row has two checks: one on the screen and one in the system behind it.

The cases run roughly from the most to the least visible. A missing required field announces itself; a lost response after sending looks, from the user’s chair, identical to a slow network. The later rows are where agents most need the table, because nothing in the happy path hints that they exist.

W3C’s form-notification guidance recommends clear feedback about submission results, including helpful error-resolution instructions. It covers overall feedback and feedback near the affected controls. Those are distinct needs: the person must know something went wrong and where to correct it, and a banner at the top of a long form answers the first without the second.

Give the agent an observable requirement. Instead of “improve error handling,” ask it to preserve valid fields, identify the rejected input and verify that the correction can be reached by keyboard. A visible message without a usable correction path is incomplete. An illustrative pass: the message names the field, focus moves to it or a link does, and the field’s own hint says what a valid value looks like. An illustrative fail: a red border and nothing else.

Keep technical details out of the primary message unless they help the user decide. A request identifier can support a help conversation; a stack trace usually cannot. Preserve diagnostic details in the appropriate test evidence rather than exposing them as the user’s next step.

W3C’s explanation of WCAG 2.2 redundant entry describes reuse of previously entered information in the same process. It includes exceptions for essential re-entry, security and information that is no longer valid. It does not require storage between sessions, and a team that reads it as “save everything forever” has taken on a storage, access and expiry problem the criterion never asked for.

For the acceptance test, distinguish correcting a field in the current process from returning days later. Preserve valid work through the former where appropriate. If the product promises a saved draft across sessions, that is an additional feature with its own storage, access and expiry behavior to verify, and it belongs in its own acceptance case rather than being smuggled in as “recovery”.

Do not solve every recovery problem by putting the whole form into persistent browser storage. Decide which values may be retained, where and for how long. Test the chosen behavior, including sign-out and shared-device use when those are relevant to the application: a form that helpfully restores a previous visitor’s medical details on a library computer has solved the wrong problem.

A server can accept a request even if the browser loses the response. In that case, immediately presenting a fresh submit action can create a duplicate if the backend has no protection. Keep the result unresolved until the application can look up the operation or safely repeat it under its documented contract. The honest state of the form at that moment is “we do not know yet”, and the interface should say so rather than guess in either direction.

If the application cannot resolve the submission automatically, show an unresolved status and a support route tied to that operation. The AI tool-error reference explains why unknown outcomes need inspection. Apply the same distinction to the form’s user-facing state without exposing internal jargon: the user sees “we are checking whether your request arrived”, the log sees the request identifier and the lookup.

This is a row agents can easily build wrong, because the natural implementation of “the request failed” is to re-enable the button. A disabled button is a courtesy; a lookup by request identifier, or an idempotency key the server honors, is the control.

Each of the illustrative patterns below is a reasonable-sounding response to one row of the table that breaks another row. They are easy to fall into because each one is what “handle errors better” means if you only have one failure in mind.

The reload reset: on any error the form reloads to a clean state, which clears the invalid value and every valid one with it. The eager retry: a lost response re-enables Submit with a “try again” hint, and the second attempt lands on a server that already saved the first. The everything-draft: to stop re-entry, the whole form is written to persistent storage on every keystroke, including the card number, with no expiry and no sign-out hook. The silent partial: in a multi-step submission the first step succeeds, the second fails, and the form reports failure for both, so the user re-does step one and creates a duplicate record there.

Each is caught by running the whole matrix rather than the one case that prompted the fix. The reload reset fails row one; the eager retry fails row four; the everything-draft fails the sign-out check in section 04; the silent partial fails row six.

Start with a filled form containing representative valid values. Trigger one specific failure, record what remains, then complete the correction and check the destination. Repeat for the relevant failure cases. Keep the test identifiers so the reviewer can distinguish an old record from the new result; a destination with two records and no way to tell which run made which has proved nothing about duplicates.

Use keyboard interaction to check focus and correction, and the rendered page to inspect message clarity. The two checks catch different defects: a message can be clear and unreachable, or reachable and useless.

If the exercise reveals a defect, use the coding-agent bug-report guide to preserve reproduction steps. For evidence attached to the fix, use the screenshot evidence reference, and for the accessibility of the error states themselves, our guide to verifying AI accessibility fixes covers the keyboard and announcement checks. Teams that want the matrix built into their form acceptance rather than remembered per project can work with our AI transformation practice.