Error functionality recommendation

[ang-twilio]

The messaging UI team is working on updating form states and validation. One question came up about form field validation.

Should error removal happen during typing when input becomes valid? Essentially error only appears on submission, but gets removed the moment input becomes valid and if it has been displayed once and you go invalid again it will display it again.

Is there a standard that Paste recommends for this case or should designers make this call? Thank you!

[kate-porter]

Hey @ang-twilio - this is a great question. We don't have formal guidance on this right now, but I do like your suggestion of removing the error message once the input becomes valid. Let me just double check to ensure there are no accessibility concerns with that approach. I'll report back!

[kate-porter]

Okay, sounds like your proposed solution will work just fine!

We may include guidance on this in a pattern at some point down the road, so if you have any usability insights from taking this approach, please do share.

[ang-twilio]

Awesome, thanks for your feedback!

[bhamtil-twilio]

As a related follow up question – I am looking at an experience that shows real-time syntax validation errors on blur/on change and removes them once the syntax is corrected. Is that acceptable for syntax errors only, or should all validation errors (including syntax) not be visible until after submit for best accessibility?

[serifluous]

Hey @bhamtil-twilio ! Syntax errors are ok to validate on change if they're validated on the client-side (and don't require waiting for communication with the backend to validate). Keep in mind that it can sometimes feel a little annoying/patronizing to users if they're being validated on every keypress—think someone typing out an email and repeatedly being told they haven't entered a full email.

We generally don't recommend using on blur for error validation. It could get tedious for users to focus in and out of the form field to check for whether the error has been removed (or even then, get a different error that gets triggered).

But as Katie said, regardless of what approach you choose, we'd love to hear any usability insights you learn so we can solidify this guidance!