USWDS - Input Mask refactor: Recovering from an error is difficult due to lack of feedback.

[amyleadem]

Summary

When usability testing participants entered invalid characters, they were not given proper feedback (4 participants) and were therefore unaware that the entered characters were disallowed.

Observations

Video clips🔒

1. It was not clear to participants what characters were valid.
2. No feedback was given after entering an invalid character (USWDS - Input Mask refactor: Recovering from an error is difficult due to lack of feedback. #5481)
3. Participants weren't sure how to correct after entering an invalid character (USWDS - Input Mask refactor: Recovering from an error is difficult due to lack of feedback. #5481)
4. The status after entering an invalid character was unclear ("Did I actually enter the character?")
5. Participants didn’t know that the characters they were typing appeared in the field or automatically got deleted by the mask.

Affected user groups

• Blind and visually impaired users who use screen readers
• All 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 🔒).

Accessibility implications

Currently, if a person is typing into the input mask component and types, for example, a letter instead of a numeral in the SSN example, there is no visible nor audible cue letting the person know of the error.

This issue causes the input mask to fail WCAG 3.3.3

Next steps

We should create an error message for when an invalid character is entered into the input mask. An invalid character is any entry that does not get added to the input value when it is typed (For example, entering a number where the mask only accepts a letter).

Entering an invalid character should trigger an error message for the end user. Here are the requirements for that error message:

• The error message should be accessible to sighted users and screen reader users
• The error message should be triggered for each invalid entry
• The error message should indicate which character is needed in this position, followed by a readout of the current input value.
  • For example, “Please enter a number here”, “Please enter a letter here”, "Please enter a [format character] here"
• The error message should be available to users of assistive technologies
• The error message text should be customizable via data attributes
• The error message should disappear upon entry of a valid character, backspace key or delete key

More details can be found in the Input mask requirements doc (🔒 Google docs).

Tip

You might be able to reference the original input mask refactor PR for inspiration.

Related issue

See more details related to usability test findings for input mask in #5525

[amycole501]

The accessibility audit reaffirms that users (both sighted and not) are unable to tell when an error occurred. This issue violates WCAG 3.3.3 Error Suggestion.

I added the label of a11y audit fails to prioritize this issue.

[amycole501]

Also to add more context I added this issue which can be related to the existing one #6119

[amyleadem]

We should investigate if this is a duplicate of #6119

[amycole501]

I believe it is; is there a way to merge the two?

[amyleadem]

@amycole501 We cannot formally merge them, but I have pulled in some of the issue description from #6119 into a new "Accessibility implications" section in this issue's description. Please feel free to add more detail there if needed.

I will close out the other issue as a duplicate.