Validating during typing flags errors before the value is complete
Aliases: keyup validation · validate while typing · premature error
What it is
Validation during typing runs the rule on the current string after every character, or before the person has declared the field done, and shows an error. An email before @, a phone missing the last two digits, a password meter turning red on the third character—all treat a mid-state as a final state. The person is still building the answer; the interface has already judged failure. This entry only explains why judging while writing reports errors on incomplete input. It does not settle blur as the right moment, and it does not cover whether red copy should vanish the instant a fix is typed. Moving focus to the failing field, or listing errors at the top, is a location problem, not a timing problem.
Why it happens
An input is an action with duration. The validator sees a prefix; the rule wants a complete value. Prefixes are almost always illegal: zhang@ is not an email, 138 is not a mobile number. Premature errors encode “not finished yet” as “you are wrong.” The format being assembled in working memory is interrupted by a red line; people stop to rewrite parts that were already right, or delete and start over. A second layer is the motor program. Fluent users type a phone number as one keystroke sequence. An error animation that steals focus or shoves layout splits that sequence, and error rate goes up. Format-sensitive fields (email, card number, date) take the worst hit, because every true prefix of a legal value fails the same regex. The rule is not the mistake. Sending mid-states to a final-state rule is.
Studying it
On the same field, compare “validate and show error per character,” “show only after a minimum length,” and “no in-typing message before submit.” Use values that are written in stages (email, international phone), not single-character fields.
Independent variables: trigger (per key / minimum length / in-typing messages off), field type (whether a legal prefix exists), whether the error shoves later fields. Dependent variables: mid-field pauses, delete-and-retype rate, time to finish the field, glances from the input to the error.
Lab tasks are short, so premature errors show up as annoyance scores more than abandonment. When error copy pushes later fields, the measure is jumpiness, not the rule—separate reserved space for copy from validation timing.
Where it stops holding
Feedback whose value is in the process—password strength, username uniqueness—needs to exist before submit: people need to know “one more character will do” or “this name is taken.” Show that as progress or suggestion, not as “the current prefix is an error.” Running validation while autocomplete is still filling stacks the animation and the red text; the mid-state is even dirtier. One-character OTP cells have no meaningful prefix, so per-cell checks are not premature. If a screen reader announces “invalid” on every character, the input channel is flooded by the error stream.
Applying it
- Do not send the current prefix through a complete-value rule and render an error while the person is still in the field. Silent checks are fine; error copy waits until the field is declared done.
- Make in-process feedback neutral: a strength bar for passwords, “checking / available” for usernames—not an error on an unfinished email.
- Reserve space for error copy so later fields do not jump even if a premature trigger slips through. That is damage control, not permission to flag early.
- Verify by typing a legal email in slow motion and noting the character at which the first error appears. If it appears before
@or before the domain is finished, timing has failed. Then turn off in-typing errors and check whether delete-and-retype on that field drops.