Search Accessible via Screen Reader and Keyboard Navigation
All three organizations serve users with diverse accessibility needs — Blindeforbundet's user base in particular requires first-class screen reader support. The search screen must implement proper semantic labels on all interactive elements, announce search results count changes via live regions, provide sufficient touch targets, and support sequential keyboard/switch navigation through results. The search input must be clearly labelled, results must be announced as they update, and empty states must be communicated via accessible text rather than image-only assets. This story ensures the search feature meets WCAG 2.2 AA requirements throughout.
User Story
Audience Summaries
Accessibility compliance is not optional — it is a contractual, regulatory, and mission-critical obligation for all three partner organizations. For Blindeforbundet specifically, whose members are blind or visually impaired, a search feature that fails screen reader standards would exclude the very population the app is designed to serve. This story delivers WCAG 2.2 AA compliance across the search interface, protecting the organizations from funding risks tied to accessibility obligations, reducing legal exposure, and demonstrating inclusive product values that strengthen partner trust and user retention. Delivering accessible search also expands the effective addressable user base — ensuring that no segment is blocked from a core discovery feature.
Customer satisfaction and long-term engagement depend on every user being able to find contacts and notes independently. This is a Phase 1 critical priority with direct impact on launch readiness.
This is a critical Phase 1 story with zero scope for deferral given WCAG 2.2 AA compliance obligations. Delivery requires coordinated input from UX, frontend development, and QA, with specific expertise in mobile accessibility testing using VoiceOver (iOS) and TalkBack (Android). Effort should account for semantic label authoring, ARIA live region implementation, focus order validation, and touch target sizing audits across all search screen states including empty states, loading states, and results lists. Acceptance criteria are well-defined and testable but require assistive technology devices or emulators in the QA environment.
Dependencies on the base search story (story-contact-and-notes-search-coordinator-001) must be resolved first. Risk: accessibility regressions introduced by later UI changes require a regression testing checklist to be maintained. Stakeholder sign-off should include a representative from Blindeforbundet to validate real-world screen reader usability before release.
Implementation requires applying semantic accessibility attributes throughout the search screen component tree. The search input must carry a descriptive `accessibilityLabel` (e.g., 'Search contacts and notes'). Result count changes must be wired to an ARIA live region (or React Native `AccessibilityInfo.announceForAccessibility`) so screen readers announce updates without focus movement. Each result list item must expose a composed accessibility label combining contact name, type (peer mentor or contact), and chapter.
Empty state components must render their message as actual text nodes — not as image-only or icon-only assets. Focus traversal order must be validated: input → filter controls → results list, using `accessibilityViewIsModal` or equivalent where needed. Keyboard return from the search input must trigger search execution and shift focus to the first result. Touch targets must meet the 44×44pt minimum.
All changes must be covered by accessibility-specific tests using tools such as jest-axe or platform-native accessibility testing APIs. Review existing component abstractions for reuse before building new ones.
Acceptance Criteria
- Given a screen reader is active, when the search screen opens, then the search input field is announced with a descriptive label (e.g., 'Search contacts and notes')
- Given search results update, when new results are rendered, then a live region announces the result count (e.g., '5 results found')
- Given the results list is navigated via screen reader, when each result is focused, then the contact name, type (peer mentor or contact), and chapter are announced
- Given an empty state is shown, when a screen reader focuses the empty state, then the empty state message is fully readable as text (not image-only)
- Given switch access navigation is used, when traversing the search screen, then focus order follows a logical sequence: input → filter controls → results list
- Given the search input has focus, when the user submits via keyboard return, then the search executes and focus moves to the first result
Business Value
Accessibility is a non-negotiable MUST HAVE for all organizations, listed as Phase 1 priority. Blindeforbundet's users include people who are blind or visually impaired and depend entirely on screen readers for app interaction. Failing to make search accessible would exclude a core user segment from a critical feature, violating both the organizations' missions and WCAG 2.2 AA compliance requirements that underpin funding and regulatory obligations.