Inline form validation 


Give users immediate validation as they’re filling out a web form.

When to use this pattern

Inline validation relies on JavaScript so should only be used as an enhancement - there should always be a server-side equivalent.

Inline validation can cause usability problems. Having content on the page change as users are typing can be distracting, and errors can be triggered erroneously. Test carefully with users.

Only implement inline validation if it genuinely improves the user experience. Two scenarios where it might be helpful are:

  • helping users enter valid passwords
  • helping users enter unique usernames

How it works

Trigger messages at the appropriate time

If you can only accurately validate the data in a field once the user has finished entering it, do this once they have moved on to another field (‘on-blur’). 

This avoids distracting users by erroneously showing them error messages as they are typing.

If there’s already an error on a field you can update the message on key-up rather than blur.

For some types of message you can validate as the user types. See the dynamic password hint text example at the top of this page.

Test with assistive devices

Inline validation relies on users noticing that part of the page has changed. Check that the service is still usable with assistive devices like screen readers.

Research on this pattern

HMRC Government Gateway

The Government Gateway team been working on a modular implementation of validation for all our forms. The aim is to provide a consistent experience for users and a generic implementation of Client side (with JavaScript) and Server Side validation. We wanted to enhance the experience, reduce errors and frustrations and increase satisfaction for users by providing timely feedback as they enter their data. 
Inline validation
  • In testing we found inline feedback is consistent with users experiences and expectations from using their everyday web sites. It provides them with help and assistance which also reflects well on HMRC. Ultimately this makes it easier for the user to provide us with the data we require.
  • Error messages are only shown on keyup if there is already an error on the input. So the user can type in a field and it won’t display an error until they blur (if it’s incorrect). If there is already an error shown when a user focuses on an input and keys up it will change the error message as you go. This implementation means the user will not get distracted by negative feedback/error messages when they initially type. Some call this implementation “lazy key up”
Example inline validation 
Summary errors
  • For Client Side validation summary errors messages are not displayed prior to the form being submitted. Displaying them at the same time as when inline error messages are displayed causes the page to jump as errors are added or removed. 
  • For Client Side validation when displaying inline errors before pressing the submit button the summary error messages are visually hidden so they are available to screen readers to stop the content moving.
  • For Client Side and Server Side summary error messaging is only displayed if the user submits the form with errors. This is the appropriate time to display the summary as the users focus is returned to the top of the page.
  • There is still the potential problem, after submit, of content moving as error messages are added or removed - see Comments and questions below. 
Example Summary errors
Dynamic hint text
  • Provides realtime positive feedback to users as they create their password, that’s while they type. Informing them when their password has met each of the criteria. This works best when an entry has to meet strict criteria like creating a password.
  • Error messaging follows the global design pattern and code implementation. This prevents exceptions being made and provides consistency.
  • In our testing to date users noticed the the dynamic hint text and it supported their entry of a valid password.