fix: revalidate confirmPassword field on password change

[Yeom-JinHo]

#68 closed

Description

This PR fixes an issue where the Confirm Password field remained valid even after the Password value was modified.
The root cause was that the confirm field’s validation was not re-triggered when the main password changed.

This update refactors the validation logic to ensure cross-field revalidation between both inputs, and improves accessibility with more accurate ARIA usage.

Changes

• Cross-field validation (major fix)

  • confirmPassword is now a controlled input (string state).
  • The match logic (isMatch) is derived with useMemo and automatically re-evaluates whenever either field changes.

• Accessibility improvement

  • Added conditional aria-invalid to only activate when the user has entered input and passwords do not match.

• UI feedback

  • Error message (“Passwords do not match”) now only appears when the user has typed something in the confirm field and the passwords differ.

• Cleanup

  • Removed redundant or unused validation conditions from the previous version (!confirmPassword && confirmPassword).

Motivation

Previously, the confirm-password input would stay in a “valid” state even after the password changed, breaking expected UX behavior.
This fix ensures immediate revalidation and a more consistent, accessible user experience when handling password confirmation flows.

Breaking Changes

• None (public API unchanged)
• Internal logic now uses string state + derived validation rather than a boolean state.

✅ Before
Confirm Password stayed green even after changing Password.

✅ After
Confirm Password instantly becomes red when Password changes.