See a Clear Message When Biometrics Are Unavailable on My Device
Not all users will have devices with biometric hardware, and some users may have biometric enrollment disabled at the OS level. Older users and users with motor or sensory impairments (a key demographic for NHF and Blindeforbundet) may use older devices or may have accessibility settings that interfere with biometric unlock. The app must gracefully detect unavailability, display a plain-language explanation, and offer a seamless fallback to password or BankID authentication. The unavailability banner must meet WCAG 2.2 AA contrast and screen reader requirements.
User Story
Audience Summaries
The partner organizations — NHF, Blindeforbundet, and others — collectively serve users with visual impairments, hearing loss, motor disabilities, and cognitive challenges, many of whom use older or accessibility-configured devices. A biometric failure state that is confusing or alarming creates immediate support burden and actively discourages app adoption among this critical demographic. This story ensures the platform is universally accessible by design, not as an afterthought. Graceful fallback handling with plain-language messaging fulfills the shared universal design mandate across all four organizations, satisfies WCAG 2.2 AA compliance requirements, and protects the app's reputation as an inclusive tool.
Accessible failure states reduce friction for the most vulnerable users and directly support the mission of each partner organization, making this story a prerequisite for responsible public release.
This high-priority story has a direct dependency on the biometric authentication story (story-biometric-session-authentication-peer-mentor-001) and must be coordinated with accessibility review and QA. Three distinct unavailability scenarios must be handled: no biometric hardware, OS-level biometrics disabled, and sensor lockout after failed attempts — each requiring specific detection logic and UI copy. Stakeholders include the UX team (plain-language banner design), accessibility reviewers (WCAG 2.2 AA contrast, screen reader semantics), and localization if multi-language support is in scope. UAT must cover assistive technology testing (VoiceOver, TalkBack) across a range of device types, including older Android and iOS models.
The six acceptance criteria map cleanly to test cases, but screen reader announcement testing requires dedicated accessibility QA tooling and testers. Delivery risk is moderate — primarily in device fragmentation and ensuring focus management is correct for screen reader flows.
Detection logic must query the platform biometric API at app launch and at authentication attempt time to distinguish between three states: hardware absent, enrollment disabled at OS level, and sensor temporarily locked. Each state maps to a specific banner message and fallback CTA. The banner component must be built using the design token color system to guarantee a minimum 4.5:1 contrast ratio — hardcoded colors are not acceptable. For screen reader support, the banner must use semantic roles (e.g., `role='alert'` or `aria-live='assertive'`), and focus must be programmatically moved to the banner on render.
The fallback CTA must navigate directly to the password login screen with no intermediate steps. On React Native, use `react-native-biometrics` or equivalent to check availability; on native code paths, handle `LAErrorBiometryNotAvailable`, `LAErrorBiometryNotEnrolled`, and `LAErrorBiometryLockout` (iOS) or their Android equivalents. Write integration tests covering all three unavailability states and snapshot/accessibility tests for the banner component.
Acceptance Criteria
- Given my device has no biometric hardware, When biometric setup is attempted, Then a banner explains that biometric login is not available on this device and I am directed to use password login
- Given my device has biometrics disabled at the OS level, When I attempt biometric login, Then a clear message tells me to enable biometrics in device settings or use password login instead
- Given biometric authentication fails due to too many failed attempts and the sensor locks, When I open the app, Then I am immediately shown the fallback login screen with a plain-language explanation
- Given the unavailability banner is shown, When a screen reader is active, Then the banner text is fully announced with appropriate semantics and focus is placed on the banner
- Given the unavailability banner is shown, When I tap the fallback action button, Then I am taken to the standard password login screen without additional friction
- Given biometric unavailability is detected, When I view the banner, Then it uses the design token color system with sufficient contrast ratio (minimum 4.5:1) for all text
Business Value
The three partner organizations collectively serve users with visual impairments, hearing loss, motor disabilities, and cognitive challenges. Many will use older devices. A confusing or alarming biometric failure state creates support burden and discourages app adoption. Plain-language, accessible fallback handling is explicitly required by the universal design mandate shared by all four organizations and is a prerequisite for WCAG 2.2 AA compliance.
Components
- Biometric Unavailable Banner ui
- Local Auth Integration infrastructure
- Biometric Authentication Service service
- Biometric Authentication Service service
- Login Screen ui
- Live Region Announcer ui
- Semantics Wrapper Widget ui
- Plain Language Error Display ui
- Contrast-Safe Color Palette Widget ui
- Biometric Authentication Service service