When registration stops, show people where to fix it

How much of “improve the error message” are we taking on?

I would first ask for the rejected screen, the values entered and the sequence of actions. A missing correction route, a mismatch in validation rules and a server outage need different changes. I would restate the request as letting people correct the fields that currently apply, without losing their input, and continue registration.

The fictional form requires name, email and attendance mode. Onsite attendance also requires a session; online attendance does not. Login, payment and attachments are outside this case. Start with “Example participant”, email “sample@”, onsite attendance and no session. The expected result is guidance for both email and session. Real applicant records are unnecessary for this reproduction.

Compare the input before rejection with the request after correction

A required marker on the screen does not prove that the server uses the same condition. Compare the field definition, client checks and server rejection with engineering. Confirm email syntax, whitespace treatment and documented length limits. Do not replace missing service rules with an arbitrary regular expression.

Pay particular attention to switching onsite attendance to online. Hiding a session while retaining its error or submitted value can leave an invisible blocker. Record actual outgoing fields as well as screenshots. Switch onsite→online→onsite and check whether an old choice returns without the person noticing.

Add a correction route and retained values to the copy change

My first option would be more specific toast text. That still leaves people searching a long form after the message disappears. For this multi-error form with a conditional field, I would choose a summary connected to inline explanations. This is a decision for this case, not a claim that every one-field form needs the same layout.

GOV.UK’s summary guidance connects errors to their inputs; its message guidance retains incorrect answers too. These change the scope from copy to focus and preserved values. W3C describes identifying the erroneous item in text, so changing a border alone is insufficient. These sources justify the design choices; they do not establish a measured registration uplift.

Specify the message, destination and next check for each field

Do not mark every empty field wrong on arrival. For this case, the first submit checks all applicable fields and presents errors in screen order. Use a summary heading such as “Check the following details” and messages that name the field. Stopping at the first error makes people discover further problems through repeated submissions.

Summary links must focus the real input, not merely scroll near a heading. A choice group links to its first operable control. The specification includes input/error associations, focus on the summary after a rejected submit and clearance from a sticky header. A screenshot of the message cannot demonstrate keyboard behavior.

After a field has failed, recheck it when the person leaves it. Remove a resolved error from both locations, update the remaining count and remove an empty summary. Do not pull focus back while they edit. A full resubmit checks new mistakes and server-only conditions again. Passing email syntax does not show that the address exists or belongs to this person.

A hidden field must not remain an invisible requirement

Switching online clears the session choice and its error and excludes it from the request. The server must also avoid using a session for online registration. Removing only the client-side required flag is not enough. Explain before the change that switching online resets the session, then give a short status message that a session is no longer needed.

Returning onsite requires a fresh choice in this example. Restoring the old selection is possible, but a session may fill up in the meantime and an old choice can be overlooked. This decision does not authorize clearing incorrect names or emails. Only the explicitly explained, no-longer-applicable session is removed. Final availability is checked by the server when registration is confirmed.

Keep input mistakes separate from service problems

Here, unavailable means the server has confirmed that the session is full. A registration deadline or event cancellation needs a separate exception design. A malformed email and a full session need different next steps. If the server confirms full capacity, preserve other input, show that the selected session is full and ask for a new choice. Do not silently register the person for another session. A displayed available place is not a reservation; engineering must verify capacity and confirmation consistently.

A missing response must not turn a correct name or email into an invalid field. Say that the registration outcome could not be confirmed and connect to a way to check evidence. Automatically resubmitting before non-application is established can cause duplicates. If the service has no outcome-checking capability yet, record that as a dependency instead of shipping a promise that it exists.

Give AI the changing conditions, not just a tone request

Asking for friendlier messages provides no basis to check when a conditional field disappears. I would supply fixed fields, validation timing and the sequence of mode changes. The prompt below is an example to reuse, not a record of a real AI conversation.

If a suggestion says to close the summary and jump to the first input after correction, check whether that steals focus. A follow-up example is: “The email was corrected but the session error remains. Retain focus and update only the remaining errors.” If it only says to hide the session, ask about its value, error and outgoing request. Put an accepted rule into the specification and its reproduction into QA, then compare them.

Review error recovery for a fictional free workshop form.
Fields: name, email, attendance mode (onsite/online), onsite session. No login, payment or attachments.
Fixed rules: name/email/mode required. Session required only onsite. Switching online clears its value/error and excludes it from the request; returning onsite requires a fresh selection.
Before the first submit, do not show errors during typing. After submit, recheck a previously failing field on blur. Every resubmit checks all currently applicable fields.
Summary and field messages match. Submit errors focus the summary; its links focus actual inputs. Rechecks do not steal focus. Keep even incorrect name/email values.
Check: onsite without session → submit → switch online → submit. Also check that correcting email updates field/summary/announcements together.
Separate input errors, confirmed session at capacity, service outage and unknown submission outcome. Email format is not ownership verification.
Return missing condition / inconsistent behavior / reproduction / expected result / engineering evidence needed. Do not invent APIs, customer data or policies.

One successful submission is not an acceptance test

Give QA starting values and action order, not “check error display.” Correcting fields and changing attendance in the same attempt exposes cases that a single rejected submit misses. Alongside each screen expectation, record outgoing fields and server behavior. A client-side pass does not demonstrate successful registration.

Follow submit→summary→error link→input with the keyboard. Check narrow widths and zoom, and verify announcements with supported assistive technology. Messages should identify the field without excessive repetition during edits. The table contains expected results before testing. Actual result, owner, environment and evidence location must be filled after execution.

Leave a handoff that can survive the next change

The planning document records the blockage, scope and choice. The specification connects applicability, wording, retention, focus, rechecks and server rejection. If engineering confirms a different format or session rule, update QA expectations as well as messages. Support needs to distinguish a field correction from checking an uncertain registration outcome.

After release, do not celebrate a lower error count alone: a missing validator can lower it too. Inspect repeated errors, resubmission outcomes and unresolved registration enquiries separately. Measure categories, fields and outcomes without collecting names or email contents. Add actual owners, rules and evidence to the handoff so another person can continue without asking for the whole story again.

Issue: error recovery in a free workshop registration form
Problem: a rejection gives no usable correction route; a hidden session error can keep blocking submission after the attendance mode changes.
Purpose: retain entered content and help users correct currently applicable fields, then continue registration.
Scope: name, email, attendance mode and onsite session. No login, payment or attachments. Independent fictional design.
Rules: name/email/mode required; session only onsite. Agree trimming, lengths and accepted formats with engineering and enforce the same rules server-side. Email syntax is not deliverability or ownership.
Mode change: switching online clears session value/error and excludes it from the request. Explain the reset beforehand and announce that no session is needed afterwards. Returning onsite requires a fresh selection. Keep name and email, including incorrect values.
Timing: no initial typing errors. On submit, check all applicable fields and list errors in screen order; do not stop at the first. Mirror summary and field messages. Server validation uses the same presentation.
Focus: submit errors focus the summary heading. Each link focuses the input or first operable choice in its group. Keep the target clear of sticky headers and associate text errors with controls.
Correction: recheck previously failing fields on blur. Remove resolved errors from both locations and update the remaining count; remove an empty summary. Do not move focus back during correction. Check newly invalid fields on the next full submit.
Messages: Enter your name / Enter your email address / Check both sides of @ in your email address (only for that condition) / Choose how you will attend / Choose an onsite session.
Full session: preserve other input, mark the selected session is full and require a new choice. Never substitute another session automatically. Recheck availability on submission. Engineering must verify capacity and registration confirmation as one consistent operation.
Service problem: do not mark correct inputs invalid. If the outcome is unknown, provide an evidence-based outcome check without claiming success/failure or automatically submitting again.
Roles: planning owns rules/messages/transitions/focus; engineering confirms client/server agreement, rejection mapping and outcome evidence; QA checks sequences and assistive technology; support distinguishes correction from service issues.
QA: empty submit, multiple errors, incorrect value retention, keyboard links, resolved errors, onsite→online→onsite, outgoing fields, server full capacity, timeout, 320px and zoom. Record actual result/version/environment/owner/evidence separately after testing.
Measurement: inspect repeated error categories and resubmission results. Never collect name/email/input values as analytics. Fewer recorded errors alone do not prove better completion.
Additional QA: choose session A → switch online → verify no session in the request → return onsite → verify A is not restored → submit without choosing and expect the required-session error. This case concerns confirmed full capacity only; deadlines and event cancellation are separate conditions.

Sources and example conditions

A fictional free-workshop form based on GOV.UK and W3C documentation checked on 28 September 2026. Attendance rules, session reset and validation timing are example decisions. Written by WekeyLab AI without company material or invented personal experience. AI prompts and corrections are examples, not execution records. Article UI checks are separate from registration-server and assistive-technology integration testing. English and Chinese localize the same Korean case.

GOV.UK Design System — Error summary

GOV.UK Design System — Error message

W3C WAI — Understanding Error Identification