-
Notifications
You must be signed in to change notification settings - Fork 1
Form validation
It’s best to validate a form on submit.
In commercial applications/ non-government work, you may have often seen instant validation as a norm. It offers additional pizzaz for that form. However, in government work, we are often building things for a wide range of humans and abilities. Their digital comfort (using the internet) levels are often wide and will include a lot of people on the lower end.
One the surface, instant validation usually is great but comes with a few problems:
- When filling a form, you're usually in 'i'm putting info down' mode.
- Instant validation interrupts that mode and forces you into 'I need to fix' mode. Every field or submission then becomes a possible interruption from one mode to another. Those micro interruptions add up and aren't great.
So, the safest way to separate the input and checking modes is to validate after submission and show clear advice on what to correct.
Another reason is instant validation is less effective for screen readers and screen magnifier users who may not see the errors because of where they appear. Not only is instant validation more cumbersome for users but it adds additional technical complexity in order to make it accessible.
There are only specific scenarios where instant validation is recommended e.g. when setting passwords. In this case, it’s useful to communicate if they've met the password criteria as you go rather than on submission.
If you need to use instant validation, please make sure your user research is backing this need.
Instant validation was popularised by a couple of institutes (Baymard Institute and Luke Wrobleswski) and the research they conducted in the early days. Sadly that research was criticised because it was based on research with only 22 users and didn't do a lot of research with assistive tech.
There are two more recent studies (2003 and 2007) conducted with over 160 users that helped show that instant validation is overall not a great idea.
https://www.upyoura11y.com/handling-form-errors/
Managed Care Review, EASi, eApp
Form validations are generally important to increase accuracy of the entered data. When there are errors with the data a user has entered, it is important to let the user know something is wrong so they can fix it.
When considering error messages, think about how you group your form fields based on your context.
Two of the more common ways to let a user know a field has errors:
- Error Summary
- Inline Errors
- Combination of summary and inline
Consider using a combination of summary and inline messages. This gives the most accessible experience for users.
An error summary provides a list of all the errors in the form at the top of the page. When validation errors have been discovered, the error summary list should display (usually at the top, but it can be anywhere).
It's a summary, you know all of the errors you have at a certain point in time. For users, it’s one place to see all the errors. For development, it’s a clear ordered list in one spot.
- Upon validation, programmatic focus should shift to the summary at the top of the page and announce.
- there should be visual indication that focus has shifted (e.g. scroll to the error summary, keep the outline on focused elements, etc).
- use of role=“alert” might be helpful to ensure the contents of the error summary are read. It’s also worth looking into aria-polite to structure priority.
- error messages should ideally be buttons/link so that clicking on the message will shift focus to and scroll to the affected field.
Inline errors show error messages in context of the field. This is beneficial as users can immediately address the issue.
- You have immediate context of what you are fixing
- Provides continuity of error context. Going from summary to a field you might forget
- Upon validation, programmatic focus should shift to the first field in error.
- The error message and the field in error should be read out to screen reader users.
The recommended approach is to combine the summary and inline errors. This creates an accessible experience where screen reader users can scan the list of errors, jump back and forth between the error summary and the field in error.
- Upon validation, programmatic focus should shift to the summary at the top of the page and announce.
- User can tab onto an error message from the list.
- Upon activating the link, the scroll position shifts and moves focus down to the field in question.
- As a part of receiving focus, the inline error message reads out.