Inline validation: when and how?

In short

Inline validation says right at the field whether a value is correct. The user doesn’t have to submit the form first and then look for the error at the top of the page.

The real question is timing. There are three options: while typing, on leaving the field and on submit. The wrong moment makes even a well-worded error message annoying.

This page covers timing and how the error is announced on the screen. How to word the message itself is in the error messages pattern; I describe the general structure of a form on the form design page.

When to validate: three moments

Figure: three moments for the same field. The boxes are the user’s steps; the box with the thick border is the moment the error first appears.

While typing

The check runs on every keystroke. On paper, this is the fastest feedback. In practice, the user sees the warning “invalid email” after the very first letter of the address.

On leaving the field

The check runs when the user has finished filling in the field and moves to the next one. Technically this is the blur event. According to Rachel Krause of NN/g, in most cases an error should only appear once the user is done with the field and moves on to the next.

Edward Scott of Baymard says the same: a field’s validity should be checked when the user leaves it. For fields such as ZIP code, phone and card number, he suggests an additional option. They can also be checked as soon as the value reaches the right length.

On submit

The GOV.UK Design System sees it differently. Its validation pattern advises against validating when the user leaves a field. The check runs when the user clicks Continue or Submit.

GOV.UK only allows validation while typing under one condition: user research must show that it solves more problems than it creates. The example is a character counter that warns when an answer gets too long.

The well-known 22% study

The most quoted figure on inline validation comes from Luke Wroblewski. In his article on A List Apart of September 1, 2009, he describes a test with Etre in London. 22 users aged between 21 and 49 tried six variations of a sign-up form.

The control version only checked after clicking “Create account”. In the best inline version, the success rate rose by 22% and errors fell by 22%. Satisfaction rose by 31%, and completion time fell by 42%.

Keep the context in mind when reading these figures. It is about a single sign-up form, 22 people and the interfaces of 2009. The result doesn’t promise the same gain in your form; it only shows the direction.

I find the finding on timing more valuable than the numbers. In the version that checked on leaving the field, participants were 7 to 10 seconds faster than in the version that checked while typing. With checking while typing, they saw an error, typed another letter and waited to see whether the message changed. If the error stayed, the game started again.

Try it: one form, three moments

The form below has an email field and a password field. When you switch the moment, the behaviour of both fields changes. The error messages are the same in every mode; only the moment they appear differs.

In “While typing” mode, you see the error at the first letter of the email. In “On leaving the field” mode, you type the same address in peace. And even if an error appears, it disappears with the letter you fix it with.

In “On submit” mode, you see both errors together in the summary above the form. Clicking a link in the summary puts the cursor in the field in question.

The problem with premature errors

A premature error tells users they are doing something wrong before they are finished. Krause says it clearly: seeing an error message before you have been able to finish typing is frustrating.

In Baymard’s testing, one participant reacted to his email being marked as wrong before he had finished typing it. According to Scott, premature validation harms the whole experience. Users stopped typing, read the message and sometimes thought a correct entry was wrong.

In Wroblewski’s test too, the version that checked before and while typing did worst. It had the highest error rate and the lowest satisfaction. Wroblewski’s recommendation: check open-ended answers only once the user is finished.

For fields with strict rules, such as the password, early help can make sense. In the test, username and password were checked while typing with a short delay in every version. Wroblewski recommends feedback while typing with a suitable delay for such cases.

I prefer to design that not as an error but as a progress indicator next to the rule.

A fixed error must disappear immediately

Validating on leaving the field also involves when the error goes away again. According to Scott, the error message should update on every keystroke and disappear as soon as a valid value is entered.

With linked fields this rule matters even more. In one example from Baymard’s test, a participant fixed the first password, but the error “Passwords don’t match” stayed until he clicked into the confirmation field again. According to Scott, the user may then believe that the corrected value is still wrong.

Success messages

A success message is the confirmation next to a correctly entered value: a check mark or a short text such as “The address format is correct”. In Baymard’s testing, these signs gave users a sense of progress. They also didn’t have to check the whole form again.

Krause, on the other hand, recommends restraint. For a field whose only rule is not to stay empty, a success message is unnecessary. It is useful when it carries information, such as whether a username is available or how strong a password is.

Wroblewski’s test brought two more lessons. Success messages that disappeared again did worse than those that stayed. And a green check mark alone confused participants: does it mean “correct” or “valid”?

That is why the confirmations in the demo come with text and appear only in the two fields with a rule. For a simple field like the name, I don’t add a confirmation. One of Wroblewski’s participants asked whether the check mark at the name field meant a valid name or a correctly spelled one.

The error summary

The error summary is the box that opens above the form on submit and lists all the errors. Whatever the moment, I always show a summary on submit. The user may also click Submit without having seen the errors from leaving the fields.

GOV.UK’s error summary component sets these rules for the box:

• The summary sits at the very top of the main content, before the page’s main heading (h1). Keyboard focus moves to the summary.
• Each entry is a link to the field with the error. For a multi-part question such as a date, the link goes to the first field with an error.
• The text in the summary is exactly the same as the error message at the field.
• The summary appears even for a single error.

The summary alone isn’t enough. Krause wants it not to be the only indication of an error. Otherwise the user has to look for the field and may forget the message by the time they get there. GOV.UK also asks for the summary and the message at the field together.

The validation pattern adds one more thing: when there are errors, “Error: ” is added to the start of the page title so the screen reader reads it as early as possible. The user’s input isn’t deleted either. When the page reloads, their values are still in the fields.

Accessibility: aria-invalid, aria-describedby, WCAG

For sighted users, inline validation works easily. For someone using a screen reader, though, the error has to be connected to the field. I put three parts together.

1. aria-invalid="true" goes on the field with the error. The W3C technique ARIA21 says the attribute shouldn’t be set before validation. Don’t mark an empty field as invalid when the page loads.

2. aria-describedby connects the field to the error text. The same technique shows an example in which the field points to the error message with this attribute. When the screen reader reaches the field, it reads the hint and the error after the label.

3. A live region (aria-live) announces the error without taking focus away from the field. The W3C lists technique ARIA19 for 3.3.1 for format errors. The “What happened?” box in the demo works this way.

This rests on two WCAG 2.2 success criteria. 3.3.1 Error Identification (level A) requires that when errors are detected automatically, the field in error is identified and the error is described in text. Colour may help, but only in addition to text.

3.3.3 Error Suggestion (level AA) goes a step further. If an error is detected and a suggestion for correction is known, it is shown to the user. If that would jeopardise the security or purpose of the content, the requirement doesn’t apply.

The message “Enter the email address in the format [email protected]” in the demo is a suggestion of the kind 3.3.3 asks for. In the password field, on the other hand, I don’t repeat the entered password in the message; in my view that weakens security. There, naming the rule is enough.

I also implemented a first step in the demo: as GOV.UK recommends, the form has novalidate so the browser’s own bubbles don’t appear. GOV.UK also always asks for validation on the server, because the check in the browser can fail. Opening the right keyboard on phones reduces errors from the start too. I describe that in the keyboard in mobile forms pattern.

Checklist

Before a form with inline validation goes live, I go through this list.

• No error appears while typing.
• The error appears on leaving the field or on submit.
• A fixed error disappears as soon as a valid value is entered.
• Linked fields are checked again when the first field changes.
• Success messages only appear for fields with a rule, and always with text.
• On submit, a summary opens at the top and focus moves to it.
• Each summary entry links to its field and has the same text.
• The field with the error has aria-invalid and aria-describedby.
• The error is described in text, not with colour alone.
• There is validation on the server too.

My note

The validation mistake I see most often in audits is the red warning at the first letter. The team builds it in as quick feedback. The user, on the other hand, feels told off before they have even started.

I take a path between the sources. A value that has been entered but is wrongly formatted I show on leaving the field. An empty field I leave to submit, because the user can go straight back to it.

I take GOV.UK’s choice of validating on submit seriously too. In a short form made of pages with one question each, this simple approach works well. In a long checkout or sign-up form, validating on leaving the field saves more time.

If you don’t know when your form shows errors, fill it in slowly yourself once. Then repeat the round with the keyboard only and with a screen reader. In the UX audit I do this check in your flow.