This content originally appeared on Adam Silver and was authored by Adam Silver
Live validation tells users whether what they type is valid as they type.
Theoritically it’s easier to fix errors as they occur instead of waiting until after form submission.
But inline validation is problematic for many reasons.
In this article I’ll explain why and what to do instead.
1. It interrupts users while they’re trying to answer the question #
For fields thats require a certain number of characters, the first keystroke will constitute an error which can slow down users in actually providing an answer.
The field could be validated after the user enters enough characters, but this means feedback would only be given when the field is valid which is pointless.
2. Validating when the user leaves the field (onblur) is distracting #
Presenting an error when the user tabs to the next field is distracting. The user is focused on the next question, not fixing their previous answer.
When the user tabs to go back to fix the error, it’ll trigger an error in the yet to be answered second field.
Related to this, is that the blur event will fire when using a password manager. So an error will be shown as soon as the user goes to use a password manager.
3. It causes the page to jump #
As the field switches between valid and invalid states, errors will appear and disappear respectively quickly.
This causes the page to jump which can be disorientating and cause users to make mistakes.
4. It’s inconsistent on fields made up of multiple inputs #
Fields that are made up of multiple inputs need to be validated as a whole.
For example, take a checkbox group that needs at least 1 to be checked. It would be premature to show an error when the user tabs over the first checkbox to focus on the second checkbox.
It would also be presumptious to validate after the user tabs past the last checkbox as they could be just exploring the options or tabbing back to a previous option.
The same issues apply to a date field consisting of day, month and year inputs.
An interface that relies on users doing things in a specific order is prone to error and takes control away unnecessarily.
We could validate these types of fields on submit, but this would be inconsistent with the way the other fields work.
5. It’s inconsistent with fields validated on the server #
Login credentials, for example, can only be validated on the server.
Like the previous point, validating some question as the user types and others on submit is inconsistent.
6. It’s inconsistent for fields with different validation rules #
Some errors can be caught as the user types, like typing a letter in an numerical input. Other types of errors can’t be caught until the user fills out the entire answer.
Again, validating different fields at different times is inconsistent and confusing.
7. Switching modes takes additional effort #
Live validation causes users to constantly switch between answering questions and fixing mistakes which increases cognitive load.
8. It can be problematic for screen reader users #
Having fields constantly switching between success and error states will mean screen readers will announce many updates in a short space of time which could be tiring.
And some screen reader users will tab through every field before answering them in order to get a feel for what’s to come.
But live validation means that every field will have errors before the user gets a chance to type their answers. This causes a lot of additional announcements which is a drain.
9. Some people might not notice the feedback #
Many people don’t look at the screen as they type, so there’s a risk that any error will go unnoticed.
10. It can be deceptive #
Some implementations of live validation show users a green check mark for a correct answer.
But a correctly formatted field checked with live validation may still be incorrect once it’s submitted.
Like Luke Wroblewski’s explains from his research on live validation:
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.
What to do instead #
Firstly, make sure your questions are easy to understand with clear instructions.
Secondly, start (and maybe end) with one thing per page.
Thirdly, forgive little mistakes like extra blank spaces.
Finally, check for errors when the user submits the form. This avoids every problem above and gives users feedback when they expect it.
Summary #
Live validation seems like a logical pattern. But in reality it’s a pattern that should be avoided.
You can avoid all the problems above by validating the form on submit giving users control and showing errors when users expect to get feedback.
And you can focus on making forms easy to use with clear guidance and well-designed questions.
That way, there’s far less chance that users will make a mistake in the first place.
This content originally appeared on Adam Silver and was authored by Adam Silver
Adam Silver | Sciencx (2017-06-26T00:00:00+00:00) 10 problems with live validation. Retrieved from https://www.scien.cx/2017/06/26/10-problems-with-live-validation/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.