Inline validation

Check a form field as the person completes it, and show the result next to the field instead of after submit.

Last reviewed

The problem it solves

A form that only checks its fields after submit hands back a list of errors at the moment the person thinks they are done. They have to find each field again, work out what was wrong, and fix it with the rest of the form in the way. Inline validation moves the feedback to the field itself, while the person is still working on it.

Luke Wroblewski's 2009 study for A List Apart compared versions of one form. The version that validated fields inline, after each field was completed, had higher success rates, fewer errors and shorter completion times than the version that validated only after submit.

When to use it

  • Fields with a format that can be checked locally: email address, postcode, date, card number.
  • Fields with rules people cannot guess, such as password requirements. Show the rules before typing starts, and mark each one as it is met.
  • Fields that need a server check, such as a username that may be taken. Check after the person pauses or leaves the field, and say clearly that a check is running.

When not to use it

  • Do not validate on every keystroke for fields that cannot be valid until they are complete. An email field marked wrong after one character tells the person nothing they do not know, and it reads as scolding. Wroblewski's study found that validating before and while people typed made the form slower to complete.
  • Do not use it as the only check. Validate again on submit, because some errors only show up across fields, and because people can skip fields.
  • Do not mark a field as valid when "valid" only means "not empty". A green tick next to a name tells the person nothing.

How to build it

Timing

Validate a field when focus leaves it (on blur). Once a field shows an error, re-check it as the person types, so the error clears the moment it is fixed. This keeps feedback early without interrupting a first attempt.

The message

  • Put the message next to the field it is about, and keep it visible while the field is being corrected.
  • Say what is wrong and how to fix it: "Enter a date as DD/MM/YYYY", not "Invalid input". WCAG 3.3.3 asks for a suggestion whenever one is known.
  • Write it in text. Colour alone does not identify an error (WCAG 1.4.1 and 3.3.1), so pair the red border with an icon and words. Check that the error text meets contrast minimums.

Accessibility

  • Link the message to the field with aria-describedby, and set aria-invalid="true" on the field while it is in error.
  • Announce errors that appear without a focus change through a live region, so screen reader users hear them (WCAG 4.1.3).
  • On submit, if errors remain, move focus to the first field in error or to a summary that links to each one.

Sources

  1. Wroblewski, L. (2009). Inline Validation in Web Forms. A List Apart.
  2. W3C. Understanding Success Criterion 3.3.1: Error Identification (WCAG 2.2).
  3. W3C. Understanding Success Criterion 3.3.3: Error Suggestion (WCAG 2.2).
  4. W3C. Understanding Success Criterion 4.1.3: Status Messages (WCAG 2.2).