Receive accessible form fields with screen reader support in the report
The post-session report feature must be fully accessible to peer mentors who rely on screen readers, particularly given that Blindeforbundet's peer mentors themselves may have visual impairments. Every dynamic field rendered in the report form must have semantic labels, correct ARIA roles, and proper focus management so that VoiceOver and TalkBack users can navigate the form in a logical sequence. The way-forward section and speech-to-text controls must also be fully accessible.
User Story
Audience Summaries
Accessibility is not a feature enhancement for this story — it is a fundamental prerequisite for the platform's relevance and legal standing. Blindeforbundet's peer mentors may themselves have visual impairments, meaning that any failure to support VoiceOver on iOS or TalkBack on Android directly excludes members of the very population the application is designed to empower. Full screen reader support on the post-session report upholds Norway's strict digital accessibility regulations and aligns with WCAG 2.2 AA compliance requirements, shielding the organisations from legal liability and reputational risk. Beyond compliance, delivering a genuinely accessible report form signals organisational commitment to inclusion, strengthens trust with Blindeforbundet's membership and leadership, and differentiates the platform as one built with — not just for — people with disabilities.
This story is marked critical for good reason: without it, the application cannot ethically or legally launch for Blindeforbundet's user base.
This critical-priority story carries significant delivery risk if deprioritised or treated as a polish task. Accessibility requirements span the entire dynamic form system, meaning it cannot be addressed in isolation — every field type, section header, validation message, and interactive control (including the speech-to-text microphone button and way-forward list) must meet ARIA and focus management standards. Delivery requires an accessibility specialist or developer with strong VoiceOver/TalkBack experience, and testing must be conducted on real iOS and Android devices with screen readers enabled — emulators are insufficient. Six distinct acceptance criteria must each be independently verified, including live region announcements for dynamic list changes and focus redirection on validation errors.
Coordination with Blindeforbundet's team for user acceptance testing with actual screen reader users is strongly recommended and may surface additional edge cases. Plan for at least one dedicated accessibility sprint or embedded accessibility review cycle. Risks include underestimation of ARIA implementation complexity and insufficient test coverage of dynamic content announcements.
Every dynamically rendered field in the report form must be implemented with full semantic accessibility. This means each input must have an associated `
The speech-to-text microphone button must expose its current state (active/inactive) via `accessibilityState.selected` and a descriptive label including the target field name. On form validation failure, focus must be programmatically moved to the first error field using a ref and `focus()`, with the error message surfaced via `accessibilityLabel` or an adjacent accessible error node. Sensitive field warnings must be announced before field content. Test with VoiceOver on iOS 16+ and TalkBack on Android 12+ on physical devices.
Snapshot and integration tests should assert on accessibility prop presence for all field types.
Acceptance Criteria
- Given a peer mentor uses VoiceOver on iOS, when they open the post-session report screen, then the screen reader announces the screen title and focuses on the first form field
- Given the report form has multiple sections, when the peer mentor navigates with swipe gestures, then each field is announced with its label, current value, and any validation state
- Given the way-forward section contains dynamic list items, when a peer mentor adds or removes an item with a screen reader active, then a live region announcement confirms the change
- Given the speech-to-text microphone button is visible, when a screen reader user focuses on it, then the button is announced as 'Activate speech input for [field name]' with its current state
- Given a form validation error occurs on submission, when using a screen reader, then focus is moved to the first error field and the error message is announced
- Given the report has sensitive fields that should be flagged, when a screen reader user focuses on such a field, then a warning is announced before reading the field content
Business Value
Blindeforbundet's entire user base includes people with visual impairments — and peer mentors themselves may be visually impaired. Full screen reader accessibility on the post-session report is therefore not optional but a core MUST HAVE requirement. Failure to support VoiceOver would exclude the very population the app is designed to serve, violating both WCAG 2.2 AA requirements and the organisations' accessibility commitments. This also protects against legal non-compliance in Norway's digital accessibility regulation.
Components
- Post-Session Report Screen ui
- Dynamic Field Renderer ui
- Speech-to-Text Field Overlay ui
- Semantics Wrapper Widget ui
- Sensitive Field Warning Dialog ui
- Live Region Announcer ui
- Activity Wizard Step Semantics ui
- Screen Reader Detection Service service
- Sensitive Field Privacy Guard service
- Focus Management Service service
- Semantics Service Facade infrastructure
- Accessibility Live Region Announcer infrastructure