WCAG 2.2 AA compliance for ActivityHistoryList
epic-contact-detail-and-edit-supporting-ui-task-004 — Audit ActivityHistoryList for WCAG 2.2 AA compliance: ensure all interactive controls are at least 44x44pt, add semantic labels to all meaningful content, verify colour contrast ratios on type labels and meta text, and add live region announcements when new pages load via infinite scroll.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Start the audit with Flutter's built-in Semantics debugger: wrap the widget in `SemanticsDebugger(child: ActivityHistoryList(...))` during a local debug run and screenshot the semantic tree — this reveals unlabelled nodes and incorrect roles faster than manual review. For live region announcements, call `SemanticsService.announce('More activities loaded', TextDirection.ltr)` inside the state listener that detects a transition from isLoading=true to isLoading=false when items.length increases. Guard with a mounted check if called from an async context. For touch target compliance, wrap the retry button in a `SizedBox(width: 44, height: 44)` and centre the visual button inside it using `Align` — this satisfies the touch target without inflating the visual size.
For contrast verification, use the design token colour names and calculate ratios against the surface token: if the design system uses CSS-style token naming, a simple Node script can verify ratios programmatically. The proxy audit badge (from task-003) should already be handled — confirm its semantics were addressed before signing off on this task.
Testing Requirements
Accessibility-focused widget tests: (1) use `tester.getSemantics()` on the retry button and assert its label is non-empty and size ≥44x44pt; (2) assert SemanticsService.announce is called after a simulated page-2 load using a spy/mock on the semantics service or by checking the semantics tree for the announcement node; (3) use `flutter test --tags=a11y` tag to mark these tests for optional CI exclusion in fast builds but inclusion in nightly runs. Additionally, document in the PR description the result of a manual VoiceOver walkthrough covering: list navigation, empty state, loading state, and error state.
Colour contrast ratios must be measured using the design token values — add a comment in the styles or token file documenting the measured ratios for type label and meta text colours.
The encrypted-field-display confirmation dialog adds interaction steps that may frustrate coordinators who access sensitive fields frequently, leading to requests to bypass the flow or skip read-receipt logging, which would violate Blindeforbundet's compliance requirements.
Mitigation & Contingency
Mitigation: Design the confirmation dialog to be as minimal as possible (one clear sentence, single confirm action) and ensure it does not reappear for the same field within a single screen session. Validate the UX with Blindeforbundet coordinators during the TestFlight pilot before finalising.
Contingency: If coordinators raise strong objections, escalate to Blindeforbundet's data protection officer to determine whether a lighter confirmation pattern (e.g., biometric confirmation instead of dialog) satisfies their compliance obligation.
The activity-history-list infinite scroll requires paginated Supabase queries. Contacts with hundreds of activities (e.g., an HLF peer mentor with 380 annual registrations) could cause slow page loads or memory pressure on older devices if pagination boundaries are set too large.
Mitigation & Contingency
Mitigation: Use a page size of 20 records with cursor-based pagination. Implement list item recycling using Flutter's ListView.builder. Benchmark memory usage with 400+ item simulation on a low-end test device before TestFlight release.
Contingency: If performance degrades on older devices, reduce page size to 10 and add a time-window filter (last 30 days, last 6 months, all) so the default view loads a manageable record count for most coordinators.
The cognitive load rule engine (from the Cognitive Accessibility feature) mandates no more than 7 fields per screen section. If a contact model has more than 7 editable fields, the edit-contact-screen layout must be split into sections, adding complexity not accounted for in the initial scope.
Mitigation & Contingency
Mitigation: Audit the full contact field list from all four organisations before implementation. Group fields into logical sections (personal info, contact details, affiliation) so no single section exceeds 7 fields. Use the cognitive-load-rule-engine component if it is already delivered by the Cognitive Accessibility feature.
Contingency: If the rule-engine component is not yet available, implement a simple manual section layout with accordion-style expansion for less-frequently edited fields to stay within the 7-field guideline without blocking delivery.