Login on a Keyboard-Aware Layout Without Field Occlusion
On mobile devices — particularly smaller form factors — the software keyboard can occlude input fields and action buttons. The login screen must use a keyboard-aware layout wrapper that adjusts the scroll position and bottom padding dynamically when the keyboard appears or dismisses. This is especially important for users with motor impairments who may take longer to type and need the field to remain stable. The behaviour must be tested on both iOS and Android with a range of keyboard heights.
User Story
Audience Summaries
Keyboard occlusion during login is a leading cause of mobile form abandonment, directly impacting peer mentor activation rates. For our target demographic — older adults and users with motor impairments — being unable to see what they are typing creates frustration that results in failed logins, support calls, and platform dropout. Resolving this at the login screen also establishes the keyboard-aware layout pattern adopted across all form-heavy flows in the app, meaning this investment multiplies in value as the product grows. A smooth, accessible login experience signals product quality from the very first interaction, supporting retention and word-of-mouth adoption among peer mentor communities.
Addressing accessibility proactively also reduces compliance risk.
This story carries high priority and is a dependency blocker for all downstream form screens. The implementation requires coordinated testing across iOS and Android device profiles, including small viewports (iPhone SE), floating keyboards, split keyboards, and large-text accessibility settings — five explicit acceptance criteria scenarios. QA must provision a matrix of physical or emulated devices to validate behaviour. The layout pattern established here will be reviewed and reused in subsequent form screens, so sign-off should include an architecture review to confirm the wrapper approach is reusable.
Effort should account for platform-specific keyboard height API differences between iOS and Android. Risk: delayed device lab access could push testing timelines.
Implementation requires integrating a keyboard-aware scroll/padding wrapper — typically `KeyboardAvoidingView` (React Native) or equivalent — around the login form container. The wrapper must respond to `keyboardDidShow` and `keyboardDidHide` events, dynamically adjusting `bottomInset` or `contentContainerStyle` based on reported keyboard height. iOS uses `padding` behaviour; Android typically requires `height` or `position` adjustment due to `windowSoftInputMode` differences. Edge cases include floating keyboards (Android), split keyboards (iPad), and large dynamic type sizes that cause content reflow.
The scroll position must be stable after keyboard dismissal with no layout jump. This component should be extracted as a shared wrapper for reuse across all form screens. Snapshot and integration tests should cover the five acceptance criteria device/keyboard scenarios.
Acceptance Criteria
- Given the login screen is displayed on an iPhone SE (small viewport), When the user taps the password field and the keyboard opens, Then the password field and sign-in button are both visible above the keyboard without manual scrolling
- Given the keyboard is open and the user fills in both fields, When the user taps sign in, Then the button is tappable and is not hidden behind the keyboard
- Given the user submits the form (e.g. by pressing the keyboard's return key), When the keyboard dismisses, Then the layout returns to its original state without visual glitches
- Given the device is an Android phone with a floating or split keyboard, When the keyboard appears, Then the form still repositions correctly to keep the active field visible
- Given a user with large text accessibility settings enabled, When the keyboard is open, Then the fields remain legible and the layout does not overflow or truncate
Business Value
Keyboard occlusion is one of the most common sources of frustration in mobile form UX. For peer mentors who are older adults or have motor challenges, being unable to see what they are typing leads to errors, failed logins, and abandonment. Fixing this at the foundation (the login screen) also establishes the layout pattern used throughout all form-heavy screens in the app, including activity registration.
Components
- Login Screen ui
- Login Form ui
- Keyboard-Aware Layout Utility infrastructure
Dependencies
- Sign In with Email and Password critical