Build Way Forward Section Widget
epic-structured-post-session-report-form-engine-task-011 — Implement the multi-entry way-forward section UI widget. Render a scrollable list of WayForwardItem cards with add, edit, and remove actions. Each item card shows action text, optional assignee chip, and status badge. Include an Add Item bottom sheet with a text field supporting speech-to-text input via SpeechToTextFieldOverlay. Apply WCAG 2.2 AA: all interactive elements have 44×44dp touch targets, semantic labels, and focus order. Wire to WayForwardTaskService via the form orchestrator.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Use a stateless widget that reads WayForwardItems from the BlocBuilder listening to the form orchestrator. Keep the bottom sheet as a separate widget class (WayForwardAddEditBottomSheet) with its own local ephemeral state (TextEditingController, selected status) to avoid polluting the orchestrator state with unsaved draft sheet values. Use showModalBottomSheet with isScrollControlled: true and padding for keyboard avoidance. For accessibility, wrap the entire bottom sheet in a FocusScope and restore focus to the triggering element on close.
Status badge colors must come from design tokens — never hardcoded hex. Use AnimatedList or a key-based ListView for smooth add/remove animations.
Testing Requirements
Widget tests using flutter_test. Test: (1) empty state renders placeholder text; (2) list with 3 items renders all 3 cards with correct text/badge; (3) tapping add button opens bottom sheet; (4) submitting add sheet dispatches AddWayForwardItem event to mock orchestrator; (5) swipe-to-delete dispatches RemoveWayForwardItem event and shows snackbar; (6) tapping undo in snackbar dispatches UndoRemoveWayForwardItem; (7) all Semantics labels are present and non-empty (use tester.getSemantics); (8) touch targets verified to be ≥44dp using tester.getSize. Also include a golden test for the card in each status variant (open, in-progress, done).
Dynamically rendered form fields built from runtime JSON schema are significantly harder to make accessible than statically declared widgets — Flutter's Semantics tree must be correct for every possible field type and every validation state. Failures here block the entire feature for Blindeforbundet's visually impaired peer mentors.
Mitigation & Contingency
Mitigation: Define WCAG 2.2 AA semantics requirements for each field type before implementation and write widget tests using Flutter's SemanticsController for every type. Include a real-device VoiceOver test session in the acceptance gate for this epic before marking it done.
Contingency: If dynamic semantics prove too difficult to get right generically, implement field-type-specific Semantics wrappers (one per supported field type) instead of a single generic renderer, accepting slightly more code duplication in exchange for reliable accessibility.
The report-form-orchestrator must manage a complex state machine — schema loading, draft persistence, per-field validation, submission retries, and error recovery — across multiple async operations. Incorrect state transitions could result in lost user data, double submissions, or UI freezes.
Mitigation & Contingency
Mitigation: Define all Bloc states and events explicitly as sealed classes before writing any logic. Use a state machine diagram reviewed by the team before implementation. Write exhaustive Bloc unit tests covering every state transition, including concurrent events and network interruption mid-submission.
Contingency: If Bloc complexity becomes unmanageable, extract draft persistence into a separate DraftManagerCubit and keep report-form-orchestrator focused solely on the submit workflow. The additional granularity makes each component independently testable.
Organisations may require field types beyond the five currently specified (text, multiline, checkbox group, radio, date). If a new type is discovered during pilot testing, the dynamic-field-renderer must be extended, potentially requiring changes across multiple layers.
Mitigation & Contingency
Mitigation: Design dynamic-field-renderer as a registry of field-type renderers with a clear extension point. Document the pattern for adding a new field type so that it can be done in one file without touching existing renderers.
Contingency: If an unhandled field type is encountered at runtime, dynamic-field-renderer renders a labelled plain-text fallback widget and logs a warning so the missing type is surfaced in monitoring, preventing a crash while making the gap visible.