USWDS - Date picker: Manually formatting date input is difficult

[mahoneycm]

Summary

Users found it challenging to manually type dates into the date picker input element.

Observations

1. It is not always obvious to screen reader users what the accepted date format is.
2. It is easy to make errors when trying to type slashes, especially for blind users. Some users prefer the slashes to be entered automatically.
3. It is not obvious when users make an error in manually typing the date due to a lack of error feedback.

Affected user groups

• All users
• Screen reader users
• Screen magnification users

Research method

1-hour 20 minute moderated usability testing sessions conducted via video conference. Conducted with 5 participants using assistive technology (screen readers and screen magnification) on a high fidelity form prototype.

More details in the findings report (Google docs 🔒).

Recommendations for next steps

1. Provide helpful error feedback when incorrect format is entered.
2. Explicitly call out in our guidance that the component should always allow for the date to also be typed in manually.
3. Consider adding input mask functionality.
4. Implement conditional formatting:
   1. Automatically add 0 for single-digit dates.
   2. Automatically enter slashes so the user does not have to type them.

Next steps

• USWDS-Site - Date Picker Guidance: Allow for manual entry
• USWDS - Date Picker: Provide helpful error feedback when incorrect format is entered. #5692
• USWDS - Date Picker: Implement conditional formatting (Consider adding input mask functionality): #5693

[mejiaj]

@mahoneycm @jaclinec

Component Feedback

Can you provide an example message or use case?

• Provide helpful error feedback when incorrect format is entered.

Masking

Could you add a little more information on what functionality exactly we need from input mask? Is it the underscores?

• Consider adding input mask functionality.

[jaclinec]

@mejiaj the W3C design system offers some examples of form errors for dates that look promising:

We could try something similar to this, but if the user enters the wrong format the error message could say something like "Please enter a valid date format MM/DD/YYYY" or similar.

I'll add this comment to #5692 as well.

[mahoneycm]

@jaclinec I agree! We actually offer these styles with the usa-form-group--error div class and a usa-error-message span. You can see them in use on the File Input (error) and Input state showcase stories

I created uswds/uswds-site#2476 in hopes of adding guidance to users on how and when to use these styles.

I also noticed that we currently have styles written to remove that sidebar in desktop widths. I think it'd be helpful to users if that error bar showed in all widths to visually group error states.

Example:

Kapture.2024-03-04.at.09.36.10.webm

Should we add this error state to our next round of user testing for feedback?

[jaclinec]

@mahoneycm totally agree that the error bar should show in all widths if possible. Otherwise, we are relying heavily on the red color to depict that there's an error which isn't accessible for color blind users.

And I'm glad you're thinking about error states and how we need to offer more guidance there! I have some thoughts and also want to share some great research the patterns team did around this - I'll add it to #2476. But generally, I think yes we need to decide on a fairly consistent look, functionality, and guidance around error states and should test it with users when we feel its in a good place to test!

[mahoneycm]

@jaclinec Removing the styles to maintain the side bar in all states should be pretty straightforward and easy. Happy to help with that after this release!