View and Understand Authentication Method Options with Accessible UI
The BankID and Vipps login screens must meet WCAG 2.2 AA accessibility requirements, which is explicitly required by all three partner organizations. This includes proper semantic labels for all interactive elements, sufficient color contrast ratios, adequate touch target sizes, support for dynamic type scaling, and compatibility with VoiceOver (iOS) and TalkBack (Android). The auth method selector must announce each option clearly and provide enough context for screen reader users to understand the choice they are making.
User Story
Audience Summaries
WCAG 2.2 AA accessibility compliance on the authentication screens is a non-negotiable legal and strategic requirement. All four partner organizations ranked universal accessibility as their second-highest priority across workshop sessions, and Norges Blindeforbund's entire user base depends on screen reader compatibility to access the app at all. NHF highlighted stroke survivors and users with cognitive challenges as key segments. An inaccessible login screen creates an immediate, total barrier — users who cannot authenticate cannot access any feature of the app.
Beyond inclusion, WCAG 2.2 AA compliance is a legal obligation for public-sector adjacent organizations receiving Bufdir government funding. Delivering compliant auth screens protects the project from legal exposure, demonstrates the platform's commitment to the full volunteer population, and is a prerequisite for partner sign-off and public launch.
Accessibility compliance on auth screens must be verified by a qualified accessibility audit before release, adding a formal QA gate beyond standard functional testing. Delivery involves coordination with all four partner organizations, as WCAG compliance was explicitly mandated by each. Testing must cover VoiceOver on iOS, TalkBack on Android, dynamic type scaling at all supported sizes, keyboard and switch access navigation, and automated contrast ratio checks against WCAG 2.2 AA thresholds (4.5:1 normal text, 3:1 large text). A recommended risk mitigation is to engage an accessibility specialist or external auditor early in the sprint, rather than at the end, to catch structural issues before rework becomes costly.
The story has a dependency on story 001 (auth method selector UI) and should be planned as a quality gate that blocks acceptance of the entire login feature, not a separate optional task.
All interactive elements on the BankID and Vipps auth screens must carry explicit semantic labels and roles consumable by VoiceOver and TalkBack — this means `accessibilityLabel`, `accessibilityHint`, and `accessibilityRole` on every button, and `accessibilityLiveRegion` on dynamic state changes such as loading indicators and error messages. Text components must respond correctly to the OS dynamic type scale without truncation or layout overflow — use relative font units and test at the largest accessibility text size. Contrast ratios must be verified programmatically and in design tokens, with no hardcoded color values that escape the design system. Focus order must follow visual reading order and be fully navigable without gesture-based swipe.
The loading state and error state must both emit accessibility announcements synchronously when they mount. Run axe-core or react-native-accessibility-engine in CI to catch regressions automatically. All acceptance criteria map directly to testable assertions that should be included in the accessibility test suite.
Acceptance Criteria
- Given I am using VoiceOver, When I navigate to the auth method selector screen, Then each button is announced with its label, role, and a brief description of what it does
- Given I am using dynamic text size set to large, When the auth screens render, Then all text scales appropriately without truncation or overlap
- Given I inspect the authentication screens, When I run a contrast ratio check, Then all text and interactive elements meet WCAG 2.2 AA minimum contrast ratios (4.5:1 for normal text, 3:1 for large text)
- Given I am navigating with keyboard or switch access, When I reach the auth screens, Then focus order is logical and all interactive elements are reachable without swiping
- Given I tap the BankID or Vipps button, When the loading state begins, Then a screen reader announcement confirms that authentication is in progress
- Given an authentication error occurs, When the error is shown, Then the error message is announced by the screen reader and includes actionable guidance
Business Value
Universal accessibility is a MUST HAVE requirement shared by all four partner organizations and was the second highest priority in all workshop sessions. Norges Blindeforbund's entire user base depends on screen reader compatibility. NHF explicitly mentioned stroke survivors and users with cognitive challenges. An inaccessible login screen creates an immediate barrier that prevents these users from accessing the app at all.
WCAG 2.2 AA compliance is also a legal requirement for public-sector adjacent organizations receiving government (Bufdir) funding.