HIGH story-email-password-login-peer-mentor-002 2 pts
2
Story Points
High
Priority
Email and Password Login
Feature

User Story

As a Peer Mentor (Likeperson)
I want to toggle the visibility of the password I am typing
So that So that I can verify I have typed my password correctly before submitting, reducing failed login attempts

Audience Summaries

Password visibility toggling is a high-priority accessibility feature that directly reduces login friction for a user base that includes peer mentors with motor impairments, cognitive challenges, and limited technical confidence. Failed logins caused by hidden-field typos generate user frustration, increase support request volume, and risk login abandonment — all of which carry real operational costs for participating organisations. By enabling users to verify their input before submitting, this feature reduces authentication failure rates, improves perceived platform quality, and signals a genuine commitment to inclusive design. This aligns with the platform's strategic objective to serve a broad, diverse user demographic without requiring technical sophistication.

This high-priority story has a clear, bounded scope but requires careful attention to accessibility compliance. The five acceptance criteria are well-defined and testable, including visual toggle behaviour, icon state changes, screen reader announcements, and focus management. QA must include assistive technology testing — at minimum VoiceOver (iOS) and TalkBack (Android) — to verify ARIA label correctness and that the keyboard does not dismiss on toggle. The toggle button must be validated against WCAG 2.1 AA contrast requirements.

No backend dependencies exist. Risk is low but accessibility testing adds time; a dedicated accessibility review pass should be scheduled before sign-off. Design must confirm the icon set and label copy ('Show password' / 'Hide password') before development begins.

Implementation requires adding a toggle button (icon-only, with explicit `aria-label`) to the right side of the password `TextInput`. Toggling switches the input's `secureTextEntry` prop between `true` and `false`. The icon must reflect current state — use two distinct icon assets or a conditional render. Critical constraint: toggling must not shift focus away from the password field and must not trigger keyboard dismissal; this requires careful handling of the `onPress` event (use `onPressIn` + `preventDefault` if needed on the platform).

The toggle button must be reachable via tab order and must announce its label dynamically via `accessibilityLabel`. Unit tests should cover all five criteria; integration tests should assert that `secureTextEntry` state toggles correctly and that focus remains on the input after each toggle.

Acceptance Criteria

  • Given the login form is visible, When the user looks at the password field, Then an eye icon toggle button is visible on the right side of the field
  • Given the password is hidden (default), When the user taps the eye icon, Then the password text becomes visible and the icon changes to indicate it can be hidden again
  • Given the password is visible, When the user taps the eye icon again, Then the password text is hidden and the icon reverts
  • Given a screen reader is active, When the user focuses on the toggle button, Then the button announces 'Show password' or 'Hide password' as its accessible label
  • Given the user toggles visibility, When the toggle state changes, Then keyboard focus remains on the password field and the keyboard does not dismiss

Business Value

Password visibility toggling directly reduces failed login attempts caused by typos in the hidden field. For peer mentors with motor or cognitive challenges — a significant subset of the user base — this is a meaningful accessibility improvement. Fewer failed logins means less frustration and fewer support requests, lowering operational costs for participating organisations.

Dependencies