The form should remember the work you did

Preserve the enquiry while Email is corrected

One rejected email address should not cost someone the enquiry they have just written. Yet an empty description returned with a validation error does exactly that: the field needing correction survives as a complaint, while the unrelated work disappears. Better wording can explain the mistake, but cannot restore discarded text. Recovery needs the permitted values to remain, the error to name Email and a usable route back to the control that needs changing.

The proposed HTML contains one rejected Email value, reader at example.invalid, beside an eighty-word project description about connecting requests and records. It sends nothing, and its browser and assistive-technology behaviour remains unverified. The retained text gives the recovery a real cost to protect: the person should be able to fix one address without composing their enquiry again. The one-error summary links to Email, where the message asks for @ and a domain. Those relationships are the starting point for following the correction.

The textarea is the useful pressure test here. Correcting Email should leave those eighty words alone, and the original email value should stay available to edit rather than be replaced by a confusing example. A server-rendered page can return safe submitted values; a client-rendered form can keep its model when applying errors. Either must encode the output appropriately. Text does not become safe executable markup because the person supplied it through our own form; preserving their work means displaying it as their data.

A useful additional case is an enquiry containing punctuation that resembles markup. Return it as the person’s text and compare it after rejection, rather than cleaning it into a different message to make redisplay convenient. The recipient may need those exact characters in a reference or technical description. This would challenge whether the recovery path both preserves the supplied meaning and applies the output encoding the destination needs.

Retention also has a scope. An ordinary project description can often remain in the current form after validation, while passwords and other sensitive values require their own handling. Automatically saving every field into long-lived browser storage introduces a different persistence and privacy decision. The immediate recovery requirement is narrower: preserve permitted work during this correction so the person can finish. Do not make a durable draft store a prerequisite unless the service actually offers and explains one. A local error should not silently become an unlimited promise about future sessions.

Give the correction a name and a place

The person needs the same name at every point in that route. A visible Email label identifies the control; its for attribute matches the input’s id, giving the association described in W3C’s form guidance.[1] Placeholder text alone would disappear as they type. The summary and nearby error should also say Email, so moving between them does not require interpreting a different name for the same problem.

The project description has its own label and remains editable. If a repeated group contains several email controls, each needs a distinct identifier and error target. A summary link that always lands in the first row can leave the later error listed yet difficult to correct. Stable names and associations let the person locate the actual rejected value instead of guessing from the position or colour of a box.

At Email, keep both the ordinary hint and the current error available. The input references them through aria-describedby, while aria-invalid and visible wording identify the rejected state. W3C’s notification tutorial describes these overall and field-level relationships.[2] They give the page a way to expose the problem; observing the actual page is still necessary to know what someone hears and sees.

The error should then stop being current when the correction is validated. Remove the stale message and invalid indication while preserving the hint and the person’s other values. If validation occurs only on submission, make that timing clear. A warning that keeps announcing the old address after a successful correction can make the person change a value that no longer needs repair.

After a rejected demonstration submit, the script moves focus to the summary using tabindex minus one. Its link then focuses Email. The specimen also uses an alert role and a polite status area for the later local result. Inspect that sequence together: multiple announcement mechanisms may repeat the same obstacle or interrupt the move to the field. The person needs one intelligible route from the overview to the rejected address, with visible focus showing where the next keystroke will go.

After correction, the demonstration reports that validation passed and no enquiry was submitted. Those are the milestones it can honestly report, because the file has no sending operation. In a working service, the person may still be waiting for the server to accept the enquiry or for another team to handle it. Give the feedback a specific meaning at that point. A field becoming valid is useful progress, but does not tell someone whether their eighty-word enquiry has reached the organisation.

<label for="email">Email</label>
<input id="email" type="email" aria-invalid="true"
       aria-describedby="email-hint email-error">
<p id="email-hint">Use an address where the team can reply.</p>
<p id="email-error">Enter an address containing @ and a domain.</p>

Test the route through failure, not just the message

Follow the recovery from the beginning: enter the description, trigger rejection, find the summary and move to Email. Source inspection found the label associations, summary target and retained eighty words in the file. The browser check still needs to observe keyboard focus and announcement order, as well as whether the displayed text survives.

Then correct the address and validate again. Compare the description before and after that attempt, and inspect whether Email’s old warning disappears at the stated validation point while its hint remains. Either half can fail independently. A retained description does not excuse a stale invalid state; a beautifully announced correction does not restore discarded work. Record the actual point where continuation breaks, so the repair addresses that loss rather than merely adding another error message.

A server rejection needs the same care. Client validation may preserve the description perfectly, while the rejected server response rebuilds an empty form. Exercise that return path after the client has accepted the address. If the service combines native browser validation with custom errors, follow the complete sequence rather than assuming each separate mechanism produces a coherent experience. The person has only one enquiry to complete.

At a narrow width or with enlarged text, check the correction where it appears. A sticky header can cover the focused summary, and a clipped container can hide the nearby message despite correct associations. Translation can also make summary and field names drift apart. These conditions matter because they can interrupt the same route that worked at the original design size; they are reasons to inspect the changed component with its real text, not shrink the message until it fits.

A failed service dependency calls for another explanation again. Marking Email invalid would tell the person to repair a value the application has not shown to be wrong. Preserve permitted input and report what is known about submission, including any uncertain outcome. This specimen does not reconcile network results or prevent duplicate sends, so a deployed form needs those rules before offering a safe retry. Keeping the address and description available is still necessary: the person may need another attempt, or an accurate account to give whoever investigates the service failure.

A one-field form may need only a nearby error and sensible focus; a longer form may benefit from the linked overview. Choose the arrangement by following the correction it offers. Here the person needs to fix Email beside eighty words already written. If the form retains those words, identifies the same field consistently and clears the resolved error, they can continue from their existing enquiry. That is a concrete result to inspect on the next attempt, without asking them to reconstruct the work the form already had.