When a filled field is hidden, say whether its data will still be submitted

What it is

Someone fills an invoice title, then unchecks “Need an invoice,” and the title field leaves the screen. Whether it will still be submitted needs a spoken rule: either the value is dropped and this order has no invoice, or the value is still in the payload and only hidden for now. Silence lets both expectations run. This entry is not about whether reveal can be guessed. It is about where already-typed data goes after hide. Reader order and maintenance complexity are separate.

Why it happens

Visibility is taken as evidence of “still on this form.” Cancelling the condition is meant to cancel that block’s consequences, including characters already typed. If a display:none input still carries the value into submit, the server issues an invoice because “there is a title,” while the person thinks they turned invoicing off. Conversely, if the UI clears the value without saying so, reopening the condition shows a blank and looks like the system ate the input. A second layer is round trips. When a condition is toggled, keeping the value makes reopen cheap, but submit must follow the current condition—a closed branch must not enter the payload. The rule can be “hide means do not submit; keep the value on the client until reopen,” but it has to sit next to the cancel action, not only in a developer comment. Wizards that park hidden values in a global store are especially good at sending closed-branch data on the last step.

Studying it

Fill a conditional block, turn the condition off, submit, inspect the payload. Open the condition again and see whether the value is back. Compare “hide still submits,” “hide excludes but keeps locally,” “hide deletes.”

Independent variables: whether the value appears in the request after hide, whether reopen restores, whether a sentence explains. Dependent variables: whether “will an invoice be issued” matches prediction, refills after reopen, a prototype of “I turned it off, why is it still there” tickets.

Do not only watch the UI. Open the request body. If the lab has a review screen next, people may catch residue there; forms without review are closer to real misses.

Where it stops holding

Draft autosave may keep hidden-branch values locally; that is a draft, not a submit. The submit API must still strip them. When regulation requires recording that something was once filled even after cancel, that belongs in an audit log, not as a business field that issues an invoice. Browsers may include hidden fields in autofill or in submit; the product rule must be enforced at serialization. CSS hide is not “do not submit.” A read-only summary that still shows a closed branch tells people it will still take effect.

Applying it

• Specify and implement: fields whose condition is currently false do not enter the submit payload. Values may stay on the client for reopen.
• On the beat the condition is cancelled, say in human language “the title will not be used on this order; it will still be here if you open this again.”
• A pre-submit review lists only currently true branches. Closed branches must not appear on the list of what will take effect.
• Verify: fill a title, uncheck invoice, capture submit; the title is absent. Reopen; the title is still in the box. Use hide-still-submits as a control, and confirm that if review shows the title, people think an invoice will be issued.

Related

• Within the group: H1.14.1 Conditional reveal must be predictable; fields must not appear or vanish without warning · H1.14.3 Dynamic reveal scrambles screen-reader linear order · H1.14.4 Too many nested branches make form logic hard to debug
• Adjacent: H1.08 Draft autosave · H1.16 Post-submit result presentation · O1.03 Purpose limitation
• Search terms: hidden field submit · conditional fields · stale value