Tutorials
Claude Opus 5.5 for form errors users can recover from
Use Claude Opus 5.5 to map each form failure to a specific recovery action before polishing the wording.
Use Claude Opus 5.5 to map each form failure to a specific recovery action before polishing the wording. A visitor asking for a product sample needs to know which field to fix, what remains saved and whether the request was actually received. A red border and “Something went wrong” do not answer those questions.
Start with states, not a screenshot
Provide the field schema, actual validation rules, server response categories and current messages. Use fictional data in examples. A community form review asks how to improve validation; discussion points include identifying the affected field and making correction easier. That is demand evidence, not an accessibility certification.
The W3C notification tutorial recommends errors that identify the field, explain correction and link to the relevant control. Use that as a design reference while verifying the actual implementation with keyboard and assistive technology.
| State | Useful response | Evidence needed |
|---|---|---|
| Required field empty | Name the field and required action | Published field rule |
| Format rejected | Explain the accepted format | Actual validator behavior |
| Server unavailable | Preserve entries and offer retry | Confirmed failure response |
| Request outcome uncertain | Explain uncertainty and check status | Request identifier or status endpoint |
| Request accepted | Confirm receipt and next step | Successful server response |
Do not describe a timeout as a confirmed rejection. Retrying an uncertain submission may duplicate the request unless the application has a safe retry mechanism. The model should flag that product decision instead of inventing a backend guarantee.
Rewrite one fictional sample request
Suppose a sample form contains email, quantity and an optional company name. Its approved rules require an email and an integer quantity from 1 to 20. “Invalid input” gives no path forward. A quantity message can instead say “Enter a whole number from 1 to 20.” For a missing email, ask for the email; do not accuse the visitor of entering a malformed address they have not typed yet.
Keep the company field optional in the rewrite. Do not add a phone requirement, mailing-list subscription or delivery promise merely to make the form sound complete. On failure, retain the valid quantity and company value. After success, show the next step that the team has actually approved, not an invented response time.
Copyable state-review prompt
Review this fictional product-sample form.
Fields: email required; quantity required, integer 1–20; company optional.
Inputs also include current labels/messages, validator rules, HTML,
and documented server states. Treat missing implementation details as unknown.
Produce a table: trigger, field or whole-form scope, message, recovery action,
values retained, focus/announcement behavior, and acceptance test.
Keep optional fields optional. Preserve valid input after failure.
Do not show a success message before a successful server response.
Distinguish confirmed rejection, unavailable service and uncertain outcome.
Do not promise duplicate-safe retries unless the supplied implementation supports them.
Provide concise messages and necessary HTML associations without redesigning the page.
Test empty submit, quantity 0/1/20/21/1.5, correction, server failure,
uncertain timeout, keyboard-only use and successful submission.
Do not submit real customer information or change a live form.The Opus 5.5 prompting reference supplies model context. This is a proposed review method, not a measured improvement in conversion or an executed Opus test.
Review behavior as well as copy
Keep visible labels. Connect field errors to their controls, and make a summary useful for reaching each problem. Decide whether focus moves to a summary or a field, then verify the choice in the actual page; adding several competing announcements can make feedback harder to follow. Clear a corrected field’s stale error without wiping unrelated entries.
For the fictional quantity rule, 0, 21 and 1.5 fail; 1 and 20 pass. These boundary checks were calculated locally, but they do not test your real server. Validate both client and server paths, including paste and a correction after the first error. A screenshot cannot establish focus order or whether a screen reader announces a message.
Connect the request to the campaign
The form should continue the promise made by the ad. Once its states work, use Panelly Studio to prepare an ad image with the approved sample offer. This does not claim a native Opus or form-building integration. Check ad-to-page consistency and reduced-motion behavior if error animations distract from correction.
Questions at handoff
**Should every error use the same message?** No. A field correction and an unavailable service require different actions. Reuse tone, not an ambiguous diagnosis.
**Does better wording prove accessibility or more conversions?** No. Test actual interaction, and measure campaign outcomes separately. The immediate deliverable is a recoverable, evidence-backed form state.
