Access Login Screen with Full Screen Reader Support
The login screen must be fully navigable and operable using iOS VoiceOver and Android TalkBack. Every interactive element — email field, password field, visibility toggle, sign-in button — must have a meaningful semantic label. Focus order must follow a logical top-to-bottom sequence. Error messages must be announced automatically. This is particularly critical for Blindeforbundet's user base but the WCAG 2.2 AA mandate applies across all organisations. The login form must pass automated and manual accessibility audits before release.
User Story
Audience Summaries
Screen reader accessibility on the login screen is a non-negotiable requirement driven by Blindeforbundet's user base, which includes members with severe visual impairments who rely on iOS VoiceOver and Android TalkBack to operate their devices. Failing this requirement at the login screen — the entry point to the entire application — would effectively exclude those users from the platform entirely, creating both a legal liability under WCAG 2.2 AA compliance obligations and a serious reputational risk for the organisations deploying the app. Accessibility compliance is increasingly scrutinised by public funders and regulators in Norway, making this a strategic obligation as much as a moral one. Passing accessibility audits at the login layer also establishes the design patterns and quality baseline that all subsequent screens must meet, reducing the overall remediation cost across the product.
Investing at this stage avoids the significantly higher cost of retrofitting accessibility into a released application.
This story depends on the email/password login story being delivered first and must be treated as part of the same delivery milestone rather than a separate iteration, since retrofitting accessibility after visual design is finalised is substantially more costly. Delivery requires coordination between the mobile developer and a QA resource with hands-on VoiceOver and TalkBack testing experience — automated tooling alone cannot satisfy the manual audit requirement specified in the acceptance criteria. The six acceptance criteria include specific focus order validation, semantic label content, error announcement timing (within 500ms), and a contrast ratio check (4.5:1 minimum), all of which must be verified on physical devices running iOS and Android. A formal accessibility audit report should be produced before release to serve as evidence of WCAG 2.2 AA compliance.
Risk: if accessibility issues are identified late, they may require layout or component changes that affect the visual design, requiring design review cycles.
Implementation requires applying semantic accessibility attributes to all interactive elements on the login screen: the email field needs an accessibilityLabel of 'Email address' with role 'text field', the password field needs 'Password' with role 'secure text field' (masking active), the visibility toggle needs a label reflecting its current state, and the sign-in button needs 'Sign in, button'. Focus order must be explicitly managed to follow the logical top-to-bottom sequence: header → email → password → toggle → button, using platform-specific APIs (accessibilityViewIsModal on iOS, importantForAccessibility on Android) where necessary. Error messages must be announced automatically via accessibility live regions (accessibilityLiveRegion='polite' or 'assertive') within 500ms of appearing, without requiring the user to navigate to them. Contrast ratios for all text elements must be verified programmatically using an automated audit tool (e.g., Axe or Lighthouse) as part of the CI pipeline, and any failures must block release.
Test coverage must include VoiceOver swipe-navigation sequence simulation and error announcement timing verification.
Acceptance Criteria
- Given VoiceOver is enabled and the login screen is displayed, When the user swipes right to navigate, Then focus moves in order: organisation name header → email field → password field → visibility toggle → sign-in button
- Given focus is on the email field, When VoiceOver reads it, Then the announcement includes the label 'Email address', the field role 'text field', and any current value
- Given focus is on the password field, When VoiceOver reads it, Then the announcement includes the label 'Password' and the role 'secure text field'
- Given focus is on the sign-in button, When VoiceOver reads it, Then the announcement is 'Sign in, button'
- Given an error occurs after form submission, When the error message appears, Then VoiceOver announces the error text within 500ms without requiring the user to navigate to it
- Given the login screen is rendered, When an automated WCAG 2.2 AA contrast check is run, Then all text elements pass a minimum contrast ratio of 4.5:1
Business Value
Screen reader accessibility for the login screen is a hard requirement for Blindeforbundet, whose members include users with severe visual impairments. A login flow that blocks screen reader users is a legal and reputational risk under WCAG 2.2 AA compliance obligations. Passing this requirement at the login layer — the entry point to the entire app — sets the accessibility baseline for all subsequent screens.
Components
- Login Screen ui
- Login Form ui
- Password Visibility Toggle ui
- Semantics Wrapper Widget ui
- Live Region Announcer ui
- Screen Reader Detection Service service
- Semantics Service Facade infrastructure
- Contrast-Safe Color Palette Widget ui
- Contrast Ratio Validator Service service
Dependencies
- Sign In with Email and Password critical