Give users immediate validation as they’re filling out a web form.
An example of dynamic hint text and inline error correction
When to use this pattern
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
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
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.