medium priority low complexity documentation pending documentor Tier 7

Acceptance Criteria

AccessibilityTestHarness: matcher reference lists every public matcher with parameter descriptions, expected values, and a minimal Dart code example
FocusManagementService: integration guide covers at least three patterns: route transition focus, dialog open/close focus restore, and programmatic focus on dynamic content reveal
AccessibilityAuditService: report schema section describes every field in AccessibilityViolation and ConsolidatedAuditReport with field name, type, and example value
LiveRegionAnnouncer: announcement API section covers enqueue() method signature, priority enum values, and a BLoC mixin wiring example showing state→announcement mapping
SensitiveFieldWarningDialog: integration checklist is a step-by-step list (≥5 items) a developer can follow to wire up the dialog for a new sensitive field type
Quick-start section for the Blindeforbundet pilot blind tester covers: how to enable VoiceOver on iOS, how to navigate the activity registration flow, and what to test and report
All code examples compile without errors (verify by running flutter analyze on snippets)
Documentation is written in English and stored in docs/accessibility/ as Markdown files

Technical Requirements

frameworks
flutter_test (for code example validation)
dart doc (optional — if API docs are generated)
apis
All five accessibility component public APIs
data models
AccessibilityViolation
ConsolidatedAuditReport
LiveRegionPriority
SensitiveFieldConfig
security requirements
Documentation must not include real user data in examples
Quick-start guide for blind tester must not expose internal API keys or environment configuration

Execution Context

Execution Tier
Tier 7

Tier 7 - 84 tasks

Can start after Tier 6 completes

Implementation Notes

Structure the documentation as five separate Markdown files (one per component) plus a quick-start guide, stored under docs/accessibility/. Cross-link between files where components interact (e.g. LiveRegionAnnouncer doc links to FocusManagementService doc for the BLoC mixin pattern). The quick-start guide for the Blindeforbundet pilot tester should be written in plain language with minimal technical jargon — this person is testing as a blind user, not as a developer.

Include a troubleshooting section in the quick-start guide covering common VoiceOver gestures needed for the activity registration flow. Reference the baseline accessibility audit report from task-017 in the AccessibilityAuditService section so future developers know where to find the debt backlog.

Testing Requirements

Run flutter analyze on all Dart code snippets embedded in the documentation to verify they are syntactically valid. Perform a peer review pass to confirm all integration guide patterns are consistent with the actual implementations delivered in tasks 002–017. The Blindeforbundet quick-start guide should be reviewed by a team member who is not the author to ensure it is understandable to a non-developer blind tester.

Component
Accessibility Test Harness
infrastructure medium
Epic Risks (3)
high impact high prob technical

Flutter's build pipeline and SemanticsService.announce() operate asynchronously. Announcements triggered too early (before the semantic tree settles) may be swallowed silently on both platforms, causing acceptance criteria around the 500ms window to fail intermittently in CI and on device, which would block pilot launch.

Mitigation & Contingency

Mitigation: Implement the LiveRegionAnnouncer with a post-frame callback delay and an internal timing guard. Write integration tests using WidgetTester.pump() sequences that verify announcement delivery across multiple frame boundaries. Validate on physical devices at each sprint boundary, not only in CI.

Contingency: If consistent announcement timing cannot be achieved within Flutter's semantic pipeline, switch to a platform channel approach that calls native UIAccessibility.post (iOS) and AccessibilityManager.announce (Android) directly, bypassing Flutter's intermediary.

high impact medium prob technical

Flutter does not natively emit a focus-gain event to Dart code when VoiceOver or TalkBack moves focus to a specific widget. If the intercept mechanism for the SensitiveFieldWarningDialog relies on an unsupported or undocumented hook in the semantics tree, it may miss focus events for some field types or in some navigation contexts, leaving sensitive data unprotected.

Mitigation & Contingency

Mitigation: Prototype the focus-intercept mechanism during the first sprint of this epic, before building the dialog UI. Evaluate Flutter's SemanticsBinding.instance callbacks and custom SemanticsActions as intercept points. Document the chosen mechanism with platform compatibility notes.

Contingency: If no reliable focus-intercept is available, implement an alternative where sensitive fields show a static 'Screen reader active — tap to reveal' overlay instead of an OS dialog, which is less seamless but achieves equivalent privacy protection without relying on an unreliable event hook.

medium impact low prob dependency

The AccessibilityTestHarness depends on internal flutter_test semantic tree APIs that can change between Flutter minor versions. If the project upgrades Flutter during this epic, the harness may break silently, causing CI accessibility tests to pass while actually skipping assertions.

Mitigation & Contingency

Mitigation: Pin the Flutter SDK version in pubspec.yaml for the duration of this epic. Document which flutter_test APIs are used and their stability tier. Add a canary test that explicitly fails if the semantic tree API surface changes.

Contingency: If a forced Flutter upgrade breaks the harness, prioritise patching the harness as a blocking task before any other epic work continues, using the canary test failure as the trigger.