Build WCAG 2.2 AA Declaration Acknowledgement Screen
epic-driver-and-confidentiality-management-ui-task-006 — Implement the DeclarationAcknowledgementScreen with full WCAG 2.2 AA compliance. The screen must include a scrollable declaration text area with a scroll-to-bottom detection mechanism that enables the confirmation checkbox only after full content has been scrolled, a checkbox confirmation widget with accessible label, timestamp recording on acknowledgement, and a submit button. All interactive elements must meet minimum 44x44dp touch targets and pass color contrast ratios.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Use a ScrollController attached to the SingleChildScrollView. In initState, add a listener: _scrollController.addListener(_onScroll). The _onScroll method checks if position.pixels >= position.maxScrollExtent - 8.0 and sets a _hasScrolledToBottom boolean in setState. This boolean gates the checkbox's enabled state.
For the checkbox, use a Row with a SizedBox(width: 44, height: 44, child: Checkbox(...)) to ensure touch target compliance — Flutter's default Checkbox may be smaller than 44dp depending on theme. Wrap the checkbox Row in a Semantics widget with label set to the required string. For the live region announcement when scroll completes, use SemanticsService.announce('You have read the full declaration. You may now confirm.', TextDirection.ltr).
Record the timestamp as a final DateTime in local widget state — do NOT persist it yet; that is task-007's responsibility. Ensure the declaration text uses Theme.of(context).textTheme styles bound to design tokens, not hardcoded font sizes, so dynamic font scaling works correctly.
Testing Requirements
Widget tests using flutter_test. Test cases: (1) checkbox is disabled on initial render, (2) scrolling to bottom enables checkbox, (3) checking checkbox enables submit button, (4) unchecking checkbox disables submit button, (5) semantics label on checkbox matches required string, (6) submit button touch target >= 44x44dp (verify via SemanticsNode rect), (7) screen renders without overflow at 200% font scale using MediaQuery override, (8) timestamp is set to a UTC ISO 8601 string when checkbox is checked. Accessibility audit using tester.getSemantics() to verify no missing labels. Color contrast must be verified manually against design tokens — document contrast ratios in PR description.
The declaration acknowledgement screen has the most complex accessibility requirements of any screen in this feature: scrollable long-form legal text, a conditional checkbox that is only enabled after reading, and a timestamp capture. Incorrect focus management or missing semantics annotations could fail VoiceOver navigation or cause the screen reader to announce the checkbox as available before the driver has scrolled, undermining the legal validity of the acknowledgement.
Mitigation & Contingency
Mitigation: Build the acknowledgement screen against the WCAG 2.2 AA checklist from the start, not as a post-hoc audit. Use semantics-wrapper-widget and live-region-announcer from the platform's accessibility toolkit. Include a VoiceOver test session in the acceptance criteria with a tester using the screen reader.
Contingency: If WCAG compliance cannot be fully achieved within the sprint, ship the screen with a documented list of accessibility gaps and a follow-up sprint commitment. Do not block the declaration workflow launch if the core interaction works but a non-critical semantics annotation is missing.
Drivers receive a push notification with a deep link to the declaration acknowledgement screen for a specific assignment. If the deep link handler does not correctly route to the right screen and assignment context — particularly when the app is launched cold from the notification — the driver may see a blank screen or the wrong declaration.
Mitigation & Contingency
Mitigation: Implement and test all three notification scenarios: app foregrounded, app backgrounded, and cold start. Use the platform's existing deep-link-handler infrastructure. Add integration tests that simulate notification tap events and assert correct screen and data loading.
Contingency: If cold-start deep link routing proves unreliable, implement a notification-centre fallback where the driver can find the pending declaration from the notification centre screen, ensuring the workflow can always complete even if the direct deep link fails.
If the driver-feature-flag-guard has any rendering edge case — such as a brief flash of driver UI before the flag value is loaded, or a guard that fails open on a flag service error — driver-specific UI elements could be momentarily visible to coordinators in organizations that have not opted in, causing confusion and potentially a support escalation.
Mitigation & Contingency
Mitigation: Default the guard to rendering nothing (not a loading indicator) until the flag value is definitively resolved. Treat flag service errors as flag-disabled to fail closed. Write widget tests covering the loading, disabled, and enabled states including the error case.
Contingency: If fail-closed cannot be guaranteed within the sprint, add a server-side RLS check on the driver assignment endpoints so that even if the UI guard leaks, the data layer refuses to return driver data for organizations without the flag enabled.