Validation usability: Evaluate use case

[jaclinec]

Summary

Users are confused and unclear on what the purpose of the validation component is. It does not match user expectations for how their information should be validated in a form input. We want to further investigate the use cases and proper implementation for validation.

Observations

4 participants (a mix of people using screen readers and screen magnification) were confused and said they weren't sure what the validation message was doing when we tested it in our form prototype. Instead of getting validation information at the top of the form, users indicated that they expect inputs to be validated inline or upon submission of the form instead.

"I guess after the point of of pressing sign in was where maybe some, it would redirect me to say invalid email, please enter a valid email address."

Video clips 🔒

Previous research from the Inclusive Interactions Team has also provided evidence that validation needs improvement:
UAT Findings presentation slide 26

Affected user groups

• All users
• screen reader users
• screen magnification users

Research method

Usability testing with 5 visually impaired participants. See details in the findings report for details. Validation summary is here.

Next steps

We will perform a landscape analysis and literature review to discover proper use cases and implementations for validation.

[jaclinec]

I've compiled over 30 sources for this research and am making headway in reviewing, but it is taking time. This is a topic that has pretty broad implications for our guidance, so after a discussion, Anne and I decided to keep the scope fairly narrow to address implications for our validation component specifically, not validation/error handling guidance in general (which is a much larger lift).

Here's the validation desk research document where I am capturing sources, notes, keywords used in search, and initial thoughts.

[jaclinec]

I've completed the Validation Component Literature Review. 🔒

The next step is sharing findings with the team.

Summary of findings:

Our validation component is unique and not commonly found in the literature nor other design systems. The closest example is a password strength indicator, which gives upfront requirements and live feedback as users type. However, unlike our component, the feedback password strength indicator is usually placed near the input field and uses colors and icons, making it more noticeable.

Our validation component also does not follow familiar form validation design conventions that users expect, leading to usability issues. Common form validation methods in the landscape include clear labels, hint text, and inline validation near inputs to help prevent mistakes. While stating validation requirements upfront is considered a best practice, they should be placed close to the input fields, not at the top of the page.

Recommendations:

1. Deprecate the validation component in its current form.
2. Consider adding a password validation component if we think it could fulfill a need for USWDS users.
3. Research and provide robust guidance on form validation and error handling best practices. It would likely be a new pattern (e.g. ‘Help a user avoid and easily fix errors’).

[jaclinec]

I shared these findings with the team in CS UX sync and the next step is Amy L and I meeting to discuss possible next steps in deprecation of the validation component from a process perspective for the component lifecycle work. This issue can be marked as done.

[brunerae]

Deprecation of this Component will be tracked in #6155