Repository navigation
Validation usability: Evaluate use case #5750
Description
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."
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.
Activity
[-]Proper validation usage is unclear: What is the use case for validation? Is it useful? Implementation guidance for validation is unclear. If there is a way it can and should be used, it is not clear from our guidance.[/-][+]Proper validation usage is unclear[/+][-]Proper validation usage is unclear[/-][+]USWDS-Site - Validation: Proper usage is unclear[/+]7 remaining items
annepetersen commentedon Apr 26, 2024
Noting I'd encourage us to start with our implementation and work in a larger look at validation later, just in terms of our current competing priorities.
jaclinec commentedon Apr 26, 2024
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 commentedon Jul 2, 2024
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:
jaclinec commentedon Jul 18, 2024
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.
[-]USWDS-Site - Validation: Evaluate use case[/-][+]Validation usability: Evaluate use case[/+]brunerae commentedon Oct 25, 2024
Deprecation of this Component will be tracked in #6155