H1.04.3clear field error on correctiondesignresearch

A field already in error should clear as soon as it is fixed

Aliases: live error clearing · error persistence · clear on fix

What it is

Once a field is in an error state and the person starts fixing it, the error should drop on the beat when the current value becomes legal. Immediate clearing means: no extra blur, no extra submit. Red copy, the outline, and “invalid” vanish as the legal value appears. The first time an error is hung on a field may wait for a completion signal; taking the error down must track the keystrokes. This entry is only about when an error state exits. It does not argue whether the first error should fire during typing, and it does not argue that blur is the stabler entry. Whether a top summary clears, and whether focus jumps, are different structures.

Why it happens

Error copy is an assertion about the current value. If the value is already legal and the assertion remains, the interface is lying. People treat that red line as a progress bar while they fix: if it stays after they are right, they cannot tell “enough,” so they keep editing or click outside again to force a recheck. A second layer is asymmetric timing. Entering an error state waits for a completion signal so mid-states are not false alarms. If leaving the error state also waits for a completion signal, “you already fixed it” is hidden until the next exit. The asymmetry is deliberate: conservative to raise, aggressive to clear. Lag in clearing also trains people to ignore red copy—the wolf came, the value is fine, the words remain, so the next real error looks like residue. Cross-field errors (two passwords disagree) must be recomputed as soon as the side being edited becomes legal; “must match the previous field” cannot stay up after they already match.

Studying it

Put a field into error, then compare three ways out: clear on the keystroke that makes it legal, clear on the next blur, clear on submit.

Independent variables: clear trigger (input / blur / submit), error type (this field’s format / match with another field), whether clearing collapses layout. Dependent variables: delay from legal value to red copy gone, extra blurs or submits, characters typed after the value was already legal, whether people still believe “red means currently wrong.”

Eye tracking that shows people re-reading error copy after the value is legal is direct evidence of lag. Layout collapse mixes “copy disappeared” with “the field jumped”; a reserved-space condition has to be run separately.

Where it stops holding

Rules that need the server (email already registered, code matches) cannot clear at keystroke speed. When the value looks locally legal, switch to “checking,” rather than keeping the last failure on screen. If “checking” times out on a slow network, drop the stale error and replace it with a timeout; do not let an expired “already taken” linger. Disabled or read-only fields cannot be corrected and should not still show a fixable error. When the whole value is undone back to empty, a required error may wait for the next exit, so clearing does not flash “required” on the empty instant.

Applying it

  • After a field enters error, rerun the same rule on input (or the equivalent value change). The moment the value is legal, drop copy, outline, and invalid state; do not wait for blur.
  • Recompute cross-field rules when either side changes. When the side being edited becomes legal, the other side’s “does not match” must disappear on the same beat.
  • For server rules, switch to “checking” once local format is legal; success clears, failure replaces with the new current reason. Never keep the sentence from the previous response.
  • Verify by making an email illegal, blurring to show the error, then completing it to a legal value without leaving the field—the red copy must already be gone. Change two passwords until they match and confirm both errors drop together. Throttle the network and check that a stale “already taken” does not remain until the next check returns.

Related

  • Within the group: H1.04.1 Validating during typing flags errors before the value is complete · H1.04.2 Validating on blur is the more stable moment
  • Adjacent: D1.01 Immediate action feedback · E6.03 Inline validation · H3.02 Three elements of error messages
  • Search terms: error clearing · inline validation · asymmetric validation

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H1.04.3