-
Notifications
You must be signed in to change notification settings - Fork 942
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
USWDS - Input Mask: (Error Feedback) Code Refactor #6203
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mejiaj thanks for the draft feedback! Good catch on that bug :O |
I think it has something to do with holding down the shift button. I will add this edge case - good catch! |
I'm working on refining the error message so that a screen reader user understands their invalid character was not added to the input. There was some confusion from users if they needed to backspace or not (and they don't need to). I'm wondering if updating the message to say "Error: please enter a number. Your last entry was not added to the value." is descriptive enough OR if we need to adjust functionality to read them back their whole input like "Error: please enter a number. Currently the input value is "a1b 2c" I notice in VO it reads the new full input value after a character has been accepted, but not when it's rejected. Thoughts? |
I prefer your second wording. And in JAWS typically nothing is read aloud for me unless I backspace to hear it. Most JAWS and NVDA users I suspect will be used to arrowing backwards to hear each character. That said, hearing the entire data field announced sounds like a great enhancement! |
Added a check for key combos in 8ac4c2a 👍 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work here @mlloydbixal ! I left some requests but it's mostly just polish and cleanup work.
Fuctionaly, this feels very close!
packages/usa-input-mask/src/index.js
Outdated
const ERROR_MESSAGE_DEFAULT = "Error: please enter a valid character"; | ||
const ERROR_MESSAGE_SR_DEFAULT = "Error: please enter a valid character"; | ||
const ERROR_MESSAGE_FULL_DEFAULT = "Maximum character count reached"; | ||
const ERROR_MESSAGE_FULL_SR_DEFAULT = "Maximum character count reached"; | ||
const ERROR_MESSAGE_ALPHA_DEFAULT = "Error: please enter a letter"; | ||
const ERROR_MESSAGE_ALPHA_SR_DEFAULT = "Error: please enter a letter"; | ||
const ERROR_MESSAGE_NUMERIC_DEFAULT = "Error: please enter a number"; | ||
const ERROR_MESSAGE_NUMERIC_SR_DEFAULT = "Error: please enter a number"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: Do we need duplicates of all of these? Since they match can we just use the default values?
const ERROR_MESSAGE_DEFAULT = "Error: please enter a valid character"; | |
const ERROR_MESSAGE_SR_DEFAULT = "Error: please enter a valid character"; | |
const ERROR_MESSAGE_FULL_DEFAULT = "Maximum character count reached"; | |
const ERROR_MESSAGE_FULL_SR_DEFAULT = "Maximum character count reached"; | |
const ERROR_MESSAGE_ALPHA_DEFAULT = "Error: please enter a letter"; | |
const ERROR_MESSAGE_ALPHA_SR_DEFAULT = "Error: please enter a letter"; | |
const ERROR_MESSAGE_NUMERIC_DEFAULT = "Error: please enter a number"; | |
const ERROR_MESSAGE_NUMERIC_SR_DEFAULT = "Error: please enter a number"; | |
const ERROR_MESSAGE_DEFAULT = "Error: please enter a valid character"; | |
const ERROR_MESSAGE_FULL_DEFAULT = "Maximum character count reached"; | |
const ERROR_MESSAGE_ALPHA_DEFAULT = "Error: please enter a letter"; | |
const ERROR_MESSAGE_NUMERIC_DEFAULT = "Error: please enter a number"; |
(would need to update where the SR values are used)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Part of an earlier discussion (may not have been tracked on this PR thread) was having the option to use different messages for screen readers so it can be more descriptive when needed. Users who can see the visual message don't need as detailed of a message. I'll get with the team about what the SR messages should be so the difference is more obvious! 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey Mandy, just checking back in on this as part of my re-review! Are we sure there are use cases where we want screen readers to have a different error message than the visual error message?
If so we can limit the amount of code maintained by relying on the same default and updating where necessary:
const ERROR_MESSAGE_DEFAULT = "Error: please enter a valid character";
- const ERROR_MESSAGE_SR_DEFAULT = "Error: please enter a valid character";
// later
const errorMsgSrOnly =
- inputEl.getAttribute("data-errorMessageSrOnly") || ERROR_MESSAGE_SR_DEFAULT;
+ inputEl.getAttribute("data-errorMessageSrOnly") || ERROR_MESSAGE_DEFAULT;
This would use the same default error message but still allow users to override with data-errorMessageSrOnly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@amyleadem can you weigh in on this? I think you began the original discussion way back when. Charlie's suggestion would mean less code to maintain but would rely on users to improve the instructions offered to screen reader users.
I'm working with @jaclinec to nail down the error messages text content but currently the only difference between the visual message and SR only messages is the use of "Error: " which was a request by @amycole501.
Example:
const ERROR_MESSAGE_FULL_DEFAULT = "You have reached the maximum number of characters allowed";
const ERROR_MESSAGE_FULL_SR_DEFAULT = "Error: You have reached the maximum number of characters allowed.";
const ERROR_MESSAGE_ALPHA_DEFAULT = "You must enter a letter";
const ERROR_MESSAGE_ALPHA_SR_DEFAULT = "Error: You must enter a letter";
packages/usa-input-mask/src/index.js
Outdated
default: | ||
errorMessageEl.textContent = errorMsg; | ||
srUpdateErrorMsg(errorMessageSrOnlyEl, errorMsgSrOnly); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
question: I'm curious when we'd want this default message to come up. Is this just used as a failsafe?
note: I was able to trigger this by rapidly entering multiple characters when the input was empty. I expected "please enter a number" error message but I don't think this needs to be a blocker for this work.
Kapture.2025-01-09.at.15.48.31.webm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I had it originally to make troubleshooting more obvious (if it fell back to default I knew something was probably wrong vs it being wrong but not noticing because it accidentally used the correct messaging.. sometimes two wrongs would make a right 😆). I've left it as a failsafe since so many edge cases have come up along the way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Funny, I can't trigger it with fast typing on the alphanumeric mask - only the numerical masks. Makes me think there's probably a solution already sitting in the code that I just need to apply to both scenarios perhaps. I'll look into it more. Good catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another note about this - I noticed it only happens if the input is completely empty before you begin rapidly typing. If there is even 1 valid character before and you type rapidly it does not fall back on the default message. Something that could be improved on but I agree shouldn't be a blocker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Polish: I noticed on the first interaction the error message starts at a larger size and then drops to a slightly smaller size. Probably not a blocker but could be nice if we can pin it down!
Kapture.2025-01-09.at.15.53.48.webm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mahoneycm I am not able to reproduce this, can you confirm it's still an issue after the latest updates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not very common but I'm still able to reproduce after doing a hard refresh on Arc, Chrome, and Safari.
Summary
Improve invalid character feedback with error message. Add error messages (customizable via data attributes) to give proper user feedback when an invalid character is not added to the input value.
Breaking change
This is not a breaking change however there two minor warnings to note:
Related issue
Closes #5481
Related Pull Request
USWDS-Site: Add changelog for input mask [#6203]
Preview link
Preview link
Problem statement
The current state of the input mask component does not provide any audio feedback and very little visual feedback to the user that the character they attempted to add to the input value was rejected. Usability testing showed they were often unaware that the characters were not allowed. The desired state would be feedback to the user via an error message and the appropriate aria-labels that offer context that their input was rejected, what the current state of the input now is, and what the input is expecting from them. This issue affects every user.
Solution
The solution is to provide an error message that is descriptive and dynamic enough so that it updates the user on what the input mask is expecting of them whether it is a letter or a number. Additional aria labeling will provide the same context to screen readers in a message that can be customized separately to give additional instruction if necessary.
Testing and review
*There should be no regressions or changes to mask functionality. This is only an error message enhancement.