Inline validation is problematic

Live inline validation informs users whether what they type is valid as they type.

Theoritically it's easier to fix errors as they occur instead of waiting until submission.

But live inline validation is problematic for several reasons. Here I'll explain what they are and what to do instead.

1. It interrupts users too early and too often

For fields thats require a certain number of characters, the first keystroke will cause an error. This means users are interrupted immediately and frequently thereafter.

The first keystroke causes an error before the user had a chance to answer the question.

You could validate when the user has entered enough characters. But this means users would only get feedback after completing the field which is worthless.

2. It's too late to validate when the user leaves the field (on blur)

You could provide feedback when the user blurs the field but this is too late—the user is now focused on answering the next question. This then draws users away from the current task.

Leaving the field causes errors to show prematurely.

Some users switch windows to use a password manager. This triggers the blur event causing the validation routine to prematurely run before the user finishes answering the question.

Tabbing to the next field causes an error in the first field. When the user tabs back to the first field the second field will have an error. Painful.

3. It causes the page to jump

As fields switch between valid and invalid states, errors will appear and disappear. This results in the page jumping which can be disorientating and cause mistakes.

The page jumps as the field switches between invalid and valid.

Errors should be hidden as the user starts to fix an invalid field. But this causes an additional page jump.

4. It cannot be applied consistently

Fields that are made up of multiple inputs need to be validated as a whole.

A group of checkboxes might need at least one to be selected to be valid. But is it an error when the user tabs over one to get to the one they want to select?

You can't validate a group of checkboxes in the same way.

Or for a date input what if the user enters a valid day and tabs to the month box. Should the field be marked as invalid?

You could validate the field when the year box is blurred. But what if the user focuses the day box, leaves it empty and tabs to the month box—shouldn't that be an error?

Design that relies on users doing something in a particular way is fragile and should be avoided.

You could validate grouped fields on submit. But this is inconsistent and can confuse people who now expect errors to show as they answer questions.

5. Some questions must be validated on the server on submission

Some questions must be validated on the server like checking login credentials. Having some things validated as the user types and some things on submit creates additional inconsistency.

6. False positives create an untrustworthy experience

Some implementations show users a green tick for a valid answer. This can provide a sense of progression and stop users needing to check their answers later.

But inline validation only checks the format which means that a correctly formatted field may still be invalid once the its submitted. This is confusing, unpleasant and untrustworthy as Luke Wroblewski's research shows:

‘Participants knew we had no way to know their correct name, so they knew that the green check mark didn’t mean “correct.” But they weren’t sure and that was the problem.’

7. It's difficult to handle pre-populated fields

Pre-populated fields cause trouble. Should we display them in the success state? If they appear to have been validated already, should we then hide the success message until they have left the field again?

8. It can't be applied consistently

Some questions can be validated as the user types like typing a letter in a numerical input. But other types of questions can't be validated like this. This creates additional inconsistency.

9. Some people might not notice the feedback

Some people don't look at the screen as they type. So there's a chance the user won't notice the error.

10. It forces users to switch contexts

Inline validation causes users to frequently switch between two modes: answering questions and fixing mistakes. This is a cognitive burden on the user.

11. Problems for screen reader users

Some screen reader users explore the fields in a form before they fill it to let them get a feel for what's coming. This could cause errors in all of the fields before the user has had a chance to answer the questions.

Summary

Inline validation causes many problems and forces users to switch modes repeatedly.

To avoid users seeing lots of errors:

  • remove unnecessary fields
  • ensure fields are well-understood with clear guidance
  • use one thing per page

And in any case, designing the perfect inline validation experience is nigh on impossible. Any potential benefit is outweighed by the problems it introduces.