User story:
As a new account creator on mobile web, I want clear and timely feedback when my password and confirm password fields don't meet requirements or don't match, so that I can quickly fix errors and complete account creation without unnecessary friction.
Background & research:
The current account creation form delays password mismatch validation until form submission and does not clear errors after the user corrects their input. This creates confusion and unnecessary friction, particularly on mobile where context-switching between fields is more error-prone. Providing validation on blur - and re-validation on subsequent edits - aligns with standard UX practices and reduces failed submissions. This task is part of the broader V3 account creation effort (T415659).
Design:
Acceptance Criteria:
Note on error severity: blur-triggered validation uses a warning state (yellow triangle + warning message). Submit-triggered validation escalates to an error state (red icon + error message + form-level error banner). These are distinct visual states and should be implemented accordingly.
Note on optimistic vs. conservative re-validation: AC8 and AC9 describe the ideal (optimistic) behavior. AC10 and AC11 describe the acceptable fallback (conservative). Implement optimistic if straightforward; fall back to conservative if re-validation on keystroke is non-trivial.
On blur - password field
- AC1: Given the user leaves the password field, when the password meets all requirements, then clear any existing password warning.
- AC2: Given the user leaves the password field, when the password does not meet requirements (e.g. fewer than 8 characters), then display an inline warning below the field.
- AC3: Given the confirm password field is already filled and the user leaves the password field, when the password is now valid and the fields do not match, then display a mismatch warning below the confirm password field.
- AC4: Given the confirm password field is already filled and the user leaves the password field, when the password is now valid and the fields match, then clear any existing mismatch warning.
On blur - confirm password field
- AC5: Given the user leaves the confirm password field, when the password field is still invalid, then do not validate confirm password - suppress any match-related feedback.
- AC6: Given the user leaves the confirm password field, when the password field is valid and the passwords do not match, then display a mismatch warning below the confirm password field.
- AC7: Given the user leaves the confirm password field, when the password field is valid and the passwords match, then display no error.
On keystroke - optimistic re-validation (ideal)
- AC8: Given a password field warning or error is already displayed, when the user types in the password field and the value now meets requirements, then clear the warning or error immediately without waiting for blur.
- AC9: Given a mismatch warning or error is already displayed, when the user types in either field and the passwords now match, then clear the mismatch warning or error immediately.
On keystroke - conservative fallback (acceptable)
- AC10: Given a password field warning or error is already displayed, when the user types in the password field, then re-validate on next blur rather than on each keystroke.
- AC11: Given a mismatch warning or error is already displayed, when the user types in either field, then re-validate on next blur rather than on each keystroke.
On submit
- AC12: Given the user submits the form, when the password field is invalid, then display the password requirements error inline below the password field regardless of prior field state.
- AC13: Given the user submits the form, when the passwords do not match, then display the mismatch error inline below the confirm password field regardless of prior field state.
- AC14: Given the user submits the form, when both the password is invalid and the passwords do not match, then display both errors simultaneously alongside a form-level error banner ("There are problems with some of your input.").
- AC15: Given the user submits the form, when client-side validation fails due to password-related errors (invalid password or mismatched passwords), then the password and confirm password fields retain their current values so the user can reveal and edit rather than retype.
Open questions:
- Can this be included in the V3 release?
- Is additional instrumentation needed to track validation error rates or correction patterns?
- Should a debounce be applied to keystroke re-validation (AC8/AC9) to avoid noisy feedback on fast typists?
- Yes, 2000ms as we do for username validation.
- How should password mismatch errors interact with other password errors? (stack vs. display as one error)
- Display only one error - whatever the API returns first.