va-file-input/va-file-input-multiple: Add support for backwards compatibility of password change/submission#2027
Conversation
This reverts commit 3a9d6f0.
|
@RyanMunsch When I enter the first character of the password, the input switched to error mode. Just confirming if that's the intended behavior? Screen.Recording.2026-03-12.at.1.01.30.PM.movAlso, it looks like the top margin on the label gets lost when the component is in error state. Can we maintain it? 
|
|
@RyanMunsch I'm not sure if this is an issue or validation would still catch at some point, but if I add a file, add a few characters to the password, and then change the file, the error state goes away even though I didn't meet the requirements (4 chars). Screen.Recording.2026-03-12.at.1.17.29.PM.mov |
|
Thanks for taking a look, @danbrady.
Yes, this is expected for the minimum password requirement story and is in line with expected behavior for emitting on change (the functionality we wanted to get rid of with the submit button pattern). You can see that is the case on the production version here
This exists on prod, but I just made a CSS update here to resolve that.
Good catch! This was a combination of a missing piece of validation in the story template component and logic in the component itself. I made an update to each, notably passing the value of |
Removes duplicate controls and allows component to reflect toggled values for `use-password-submit-button-pattern` prop
jeana-adhoc
left a comment
jeana-adhoc
left a comment
There was a problem hiding this comment.
I found a few things...
-
For the stories that have a minimum password requirement, focus is returning to the component instead of going into the file password field when the file is successfully uploaded.
-
Can we add the same alert in the 'default' (no submit button) password variant that is also in the submit button variant. We should have an equitable experience here.
-
I did not catch this in the first round of review, so we can leave this as a known issue, but, we should add a unique accessible name to the multi-file upload password fields, and we should make the label consistent between the submit button/no submit button variations.
I would make the visible label File password, and the aria-label="File password for $fileName" This ensures that if someone just uploads files and then goes back to add passwords they know which file the field is associated with.
| * to the password input field for encrypted files. When false, only the | ||
| * password input field will be rendered for encrypted files. | ||
| */ | ||
| @Prop() usePasswordSubmitButtonPattern?: boolean = true; |
There was a problem hiding this comment.
suggestion (not blocking): I generally prefer to always default a component prop to false (opt-in pattern) which would mean in this case changing the name of the prop to something like disablePasswordSubmitPattern and defaulting to false. But I think in this specific case it can be argued either way (there's some cognitive load for downstream consumers to reason about turning a "disable" prop to "true") so this is just a non-blocking suggestion.
There was a problem hiding this comment.
Yeah, I generally have the same preference. I was on the fence about changing it to accommodate a default false value, but ultimately decided to keep the original name without having a strong reason to other than Jeana had already written the ADR to describe the variants. Additionally, I would usually assume that setting a prop that renders a different variant of the component to true would indicate that the rendered output of that variant is not the "default" version, which is the opposite of the direction we want to go in with these changes (hopefully that makes sense here as it does in my head 😆).
I'll update the prop name/default now.
|
Good catch on those missed updates, @jamigibbs. Thank you! |
jeana-adhoc
left a comment
jeana-adhoc
left a comment
There was a problem hiding this comment.
Thank you for all your work on this @RyanMunsch and the back and forth with me...
I've tested this on
- Edge & Chrome with NVDA & JAWS
- Safari & Chrome with VO on Mac
- Safari with VO on IOS
- Talkback on Android
In all cases the fields operated as exepected.
- Focus went to the password field on file submission
- We added the warning alert to both the default and the submit button version
- File password label and file name were announced
- In cases where there were a validation error on not a long enough password, we updated the error message to read
Enter a password with at least 4 characters - We added an ADR for this work
Marking this as approved!
5 participants
Chromatic
https://5851-file-input-pw-flag--65a6e2ed2314f7b8f98609d8.chromatic.com
Summary
This PR update
va-file-inputandva-file-input-multipleto support the existing behavior for encrypted file passwords (event emission on change of nestedva-text-inputfor password) and the new pattern that includes a submit button for the inputted password.Description
This PR re-implements the updates to va-file-input and va-file-input-multiple that introduced the new password submit button pattern from PR #1997, while adding backward compatibility for the existing pattern that uses only a password text input and emits vaPasswordChange.
Backward compatibility is supported through a new disablePasswordSubmitButtonPattern prop (default: false) on both components. When this prop is true, the password section conditionally excludes the submit button from being rendered, emits vaPasswordChange on input of the va-text-input component, and uses updated event-handler logic.
This backward compatibility is needed because the Claims Status Tool team cannot currently adopt the submit-button pattern version of file input in their app without significant business-logic changes. Supporting both patterns allows the forms system to adopt the new submit-button pattern now, while giving the Claims Status Tool team time to prepare for eventual deprecation of the original pattern.
Related tickets and links
Closes department-of-veterans-affairs/vets-design-system-documentation#5851
Screenshots
If there are any visual changes, screenshots should be added here.
Using new default password pattern
Using disable password submit button pattern
Testing and review
Provide any testing instructions or review steps as needed.
Approvals
See the QA Checklists section below for suggested approvals. Use your best judgment if additional reviews are needed. When in doubt, request a review.
Approval groups
Add approval groups to the PR as needed:
QA checklists
Use the QA checklists below as guides, not rules. Not all checklists will apply to every PR but there could be some overlap.
In all scenarios, changes should be fully tested by the author and verified by the reviewer(s); functionality, responsiveness, etc.
✨ New Component Added
minorlabel🌱 New Component Variation Added
minorlabel🐞 Component Fix
patchlabel♿️ Component Fix - Accessibility
patchlabel🚨 Component Fix - Breaking API Change
majorlabel🔧 Component Update - Non-Breaking API Change
minorlabel📖 Storybook Update
ignore-for-releaselabel🎨 CSS-Library Update
css-librarylabel