A filled form still needs its questions

The answer does not tell you the question

Both boxes contain alex@example.invalid. Which one sends invoices, and which one sends delivery updates? The empty form answered that through placeholders saying Billing email and Delivery updates email. Filling it in removed the questions. The identical values make the loss particularly obvious: the person reviewing the form has two answers in front of them and no longer has the information needed to tell what either one will do.

That purpose is still needed after typing, whether the addresses match or differ. Someone may return after an interruption, check the finance inbox or correct the dispatch contact. They should not have to remember the vanished placeholder to understand the consequence of their edit. Leaving the question visible gives them a way to review what the form will cause, rather than merely confirm that each box contains a valid-looking address.

The downloadable HTML contains original static specimens for this exact case, including deliberately weak placeholder-only controls, persistent labels and an error state. It sends no information and uses a reserved invalid-domain address. Comparing their markup shows which relationships are expressed in each state. Whether the implemented flow puts focus in the right place after submission needs an interaction check as well; a label association and a working recovery route answer different parts of the person’s task.

Let the label name the purpose

W3C’s forms tutorial recommends labels that describe a control’s purpose and an explicit or implicit association between label and control. [1] In the improved specimen, label with for="billing-email" points to the input with that id. The delivery field has its own identifier and label. The visible question and the programmatic association refer to the same control, rather than merely appearing close to it in a layout.

That association matters beyond reading the page visually. The tutorial explains its role for assistive technology and the clickable label area. [1] Keep identifiers unique when repeating a component. If two fields accidentally share an id, the intended relationship is no longer expressed reliably by their apparent proximity. A component can look correct in a screenshot while its markup points the label somewhere else.

The labels need to distinguish the purposes. Two controls both labelled Email have names, but do not explain why the address is requested twice. Billing email and Delivery updates email preserve that distinction before and after entry. If the product cannot explain separate uses, removing one question may be preferable. Where both are needed, their labels should identify the different destination decisions the form records.

“Use the billing email for delivery updates” can copy a value or create an ongoing link. Suppose both initially show alex@example.invalid and the person later changes billing to a finance inbox. Under a copy policy, delivery keeps the original address until separately edited. Under a link policy, delivery follows the billing change. Neither behaviour is established by the two equal values, so explain which one the shortcut creates and show the resulting destinations when the person reviews the form. The persistent labels identify which answer was changed and which was copied or linked. Without that distinction, an apparently convenient checkbox can redirect updates even though the person only intended to change where invoices go.

A hint explains what the question leaves open

Under the billing label, the example says “We send invoices to this address.” Under the delivery label, it says “We send dispatch updates to this address.” These hints explain consequences. They are not copies of the label in a smaller, paler font. Someone can use them to decide whether the finance inbox or the person receiving parcels is the appropriate answer.

The hint has its own identifier, referenced by aria-describedby on the input. W3C’s instructions tutorial describes ways to associate supporting instructions, including this attribute, and explains limitations of placeholder instructions. [2] The distinction is useful: the label gives the control its name, while the hint adds context. Do not make the hint carry the whole question and leave the label as an unexplained icon or a generic “Details”.

Provide a format example when it changes what the person must enter, but do not confuse an example with a requirement. A field asking for an internal reference may accept several valid structures even if the hint shows one. If the backend requires a particular format, explain the actual constraint in ordinary language. A beautifully styled hint that contradicts validation creates a problem later and gives the person little reason to trust either.

The hint may answer the question that matters most: who receives this, what happens next or why the form wants a second address. Calling it supporting information does not make that answer optional. Give it readable contrast and room to wrap beside its input as the page narrows. Moving the explanation into a distant footnote would keep every word technically present while making the reader perform the association the component was supposed to preserve.

An error is another state of the same conversation

The error specimen preserves the entered billing value alex@, retains the label and hint, and adds “Enter a billing email in the format name@example.com”. The input marks the invalid state, and its description references both the hint and error text. The person can still see which question they answered and what correction is needed. Clearing the value would make them reconstruct the attempt as well as interpret the error.

The example also includes an error summary linking to the affected input. GOV.UK’s component guidance uses both a summary and messages beside erroneous answers, with matching wording and a route to each field. [3] That gives two useful perspectives: an overview of what prevents progress and local detail at the place of correction. For a production interaction, implement and test the focus behaviour as well; a static link specimen does not demonstrate a complete validation experience.

Be precise about the failure. An invalid email format, a temporary server problem and a business rule rejecting a destination are different events. “Something went wrong” does not tell the person whether to edit their answer, wait or contact somebody. Equally, do not label a valid address invalid because the remote service timed out. The error text should reflect what the application actually established, rather than translate every failure into a complaint about the user’s input.

Some fields should not retain sensitive values after a failure; that decision depends on the data and context. The principle is to preserve recoverable work appropriately, not to store every answer forever. For ordinary contact details in this teaching form, the retained value helps correction. For a real flow, include its privacy and session rules in the state design rather than letting an all-purpose form library make the decision accidentally.

Review the form after it stops being empty

Start with alex@example.invalid in both fields and a person intending to change only the invoice destination. Billing email and its hint identify the answer they need to edit; Delivery updates email still names the separate dispatch decision. Where a copy shortcut was used, the delivery value remains independent. An ongoing link instead needs to show that the billing edit will also change delivery. If the new billing entry is alex@, its summary link and local format error should return the person to that billing answer while preserving the valid delivery address. The filled form now carries the distinctions needed to finish this particular correction.

Inspect the keyboard route and the accessible names in the actual implementation. Verify label associations, hint and error relationships, focus after a failed submission and the appearance at narrow widths or larger text. A DOM association is necessary evidence for some behaviours; it is not a substitute for exercising the complete interaction with the supported tools.

A placeholder can still offer a short example when the purpose and essential instructions remain visible elsewhere. Here, Billing email and Delivery updates email need to survive entry, matching values and an error. That lets the person check the form without deleting an address to recover its question. It is a modest requirement, but it changes the filled page from a pair of plausible values into two decisions somebody can actually review.