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.
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.
- 01Keep valid work.Correcting one error should not erase unrelated answers in the same process.
- 02Explain the next action.Give a specific field correction or a meaningful status, not only a red banner.
- 03Resolve uncertain outcomes.A lost response does not establish that the server rejected the submission.
01 — Specify the recovery state for each failureSpecify the recovery state for each failure
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.
| Failure case | User should retain or see | Acceptance check |
|---|---|---|
| Missing required field | Valid answers plus a specific correction | Correct the missing value and finish without re-entering unrelated fields. |
| Server rejects a value | Submitted values and the server’s relevant error | Fix the rejected field; verify the revised payload. |
| Connection fails before sending | Recoverable input and a clear unsent state when known | Restore connectivity and submit the preserved values. |
| Response is lost after sending | Input or receipt context plus an unresolved status | Inspect the operation before offering a potentially duplicate attempt. |
| Login expires during entry | A stated route to reconnect and recover permitted work | Verify what can be preserved and what must be entered again. |
| One part of a multi-step submission fails | Completed and incomplete parts identified separately | Resume only the unresolved part under the application’s contract. |
02 — Make the error useful to the person reading itMake the error useful to the person reading it
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.
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.
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.
03 — Retain useful input without promising permanent storageRetain useful input without promising permanent storage
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.
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.
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.
04 — Do not confuse missing confirmation with rejectionDo not confuse missing confirmation with rejection
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.
This is an application requirement, not a property that a visual test can prove alone. Ask the agent to inspect the destination record and identify the submission. If the system cannot resolve an uncertain outcome automatically, give the user a clear status and an appropriate support route.
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.
05 — Give the coding agent a complete recovery exerciseGive the coding agent a complete recovery exercise
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.
Use both keyboard interaction and the rendered page. Inspect focus and message clarity; then check that the accepted data matches what the person intended to send. A screenshot can show the error text, but it cannot alone prove that correction and resubmission work.
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 .
06 — DecisionWhat to do next
Accept the recovery path as part of the form.
Keep valid input, explain the specific correction and resolve uncertain submissions before another attempt. The form is ready when a person can recover and the destination state supports the result shown.
For implementation support, explore our AI transformation services.