Verify App Meets WCAG 2.2 AA Accessibility Standards Through Automated Audit

Confidence in screen reader support requires ongoing automated verification, not just initial implementation. The accessibility-audit-service must provide a runtime audit capability that checks all screens for WCAG 2.2 AA compliance — contrast ratios, touch target sizes, label completeness, and focus order correctness. The wcag-compliance-checker must validate semantic correctness against the WCAG criteria applicable to Flutter (1.1.1 non-text content, 1.3.1 info and relationships, 2.4.3 focus order, 4.1.2 name, role, value). The ci-accessibility-lint-runner must run automated checks as part of the build pipeline. The accessibility-test-harness must support integration tests that simulate screen reader navigation patterns to catch regressions automatically.

HIGH story-screen-reader-support-coordinator-007 8 pts

Story Points

High

Priority

Screen Reader Support

Feature

User Story

As a Coordinator

I want to be confident that the app consistently meets WCAG 2.2 AA standards across all screens, so that the screen reader experience is predictable and reliable

So that I can trust the app to work correctly with my screen reader every time I use it, without encountering unexpected unlabelled elements, broken focus order, or missing announcements

Acceptance Criteria

Given the accessibility-audit-service runs on a screen, when the audit completes, then it reports any elements missing labels, incorrect roles, or inadequate contrast as structured warnings
Given the CI pipeline runs on a pull request, when the flutter-accessibility-lint-config rules are applied, then violations are reported as build failures for WCAG 2.2 AA criteria
Given the accessibility-test-harness is used in an integration test, when simulating VoiceOver navigation through the activity registration wizard, then the test asserts that all 5 steps have correct step labels and focus management
Given the wcag-compliance-checker evaluates touch targets, when any interactive element has a tap target smaller than 44x44 points, then it is flagged as a violation
Given the contrast-ratio-validator runs on the current theme, when any text/background combination fails 4.5:1 minimum for normal text, then the violation is surfaced with the element identifier and actual ratio
Given a new generator adds a custom widget without a Semantics wrapper, when the ci-accessibility-lint-runner scans the codebase, then it flags the missing semantics annotation as a warning

Business Value

Accessibility is not a one-time implementation — it degrades as new features are added if it is not actively maintained. Automated auditing closes the feedback loop between development and accessibility quality. For a product serving multiple disability organisations with contractual WCAG 2.2 AA obligations, catching regressions before release protects the organisation from legal risk, user trust erosion, and the expensive manual remediation that inevitably follows when accessibility is only checked manually. A CI-integrated accessibility lint runner makes compliance a team norm, not an afterthought.

Components

Accessibility Audit Service service
Accessibility Test Harness infrastructure
WCAG 2.2 AA Compliance Checker infrastructure
Cognitive Accessibility Audit Utility infrastructure
Accessibility Design Token Enforcer infrastructure
Contrast Ratio Validator Service service
Token Accessibility Enforcer service
Accessibility Token Manifest data
CI Accessibility Lint Runner infrastructure
Flutter Accessibility Lint Configuration infrastructure
Accessibility Audit Runner infrastructure

Dependencies

Navigate the App Fully Using a Screen Reader critical

Screen Reader Support

Related Feature

Coordinator

User Role