Validate lint configuration in CI dart analyze step
epic-visual-design-accessibility-foundation-task-013 — Integrate the Flutter Accessibility Lint Configuration into the CI pipeline by adding a dart analyze step that uses the configured analysis_options.yaml. Confirm that deliberately introduced violations (e.g., a hardcoded color, missing semantics label) are caught and cause the CI step to fail, and that clean code passes without warnings.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 6 - 158 tasks
Can start after Tier 5 completes
Implementation Notes
Place lint fixture files under test/lint_fixtures/ and exclude them from the main lib/ tree so they never ship to production. In the CI YAML, use a matrix or sequential steps to run dart analyze --fatal-infos --fatal-warnings separately on each fixture, asserting the expected exit code. For violation fixtures, the step should expect exit code 1 (use `dart analyze || true` piped through an exit code assertion pattern, or a shell script wrapper). For the passing fixture, assert exit code 0.
Use a dedicated accessibility_lint_rules.yaml included by analysis_options.yaml via the include: directive — this keeps accessibility rules versioned separately. Document the CI step with a comment block: '# Accessibility lint: enforces WCAG 2.2 AA at build time. Required for NHF/Blindeforbundet/HLF user base.' If the CI system is GitHub Actions, use the dart-lang/setup-dart action to ensure consistent SDK version.
Testing Requirements
Validation is done via intentional violation fixtures. Maintain a ci_lint_fixtures/ directory with: (1) violation_hardcoded_color.dart — contains a hardcoded Color literal; (2) violation_italic_font.dart — contains fontStyle: FontStyle.italic; (3) violation_thin_font.dart — contains FontWeight.w100/w200/w300; (4) clean_passing.dart — uses only token references, meets all rules. In CI, run dart analyze on each fixture and assert exit codes. This acts as a smoke test for the lint configuration itself.
Do not include fixture files in production build paths (exclude from lib/).
The WCAG 2.2 relative luminance formula requires gamma-corrected sRGB calculations. Floating-point rounding differences between Dart and reference implementations could produce off-by-one classifications for near-threshold color pairs, resulting in pairs that just pass or just fail in CI but behave differently at runtime.
Mitigation & Contingency
Mitigation: Implement the algorithm directly from the WCAG 2.2 specification using the exact linearisation constants. Validate the Dart implementation against the W3C reference test vectors and against a known-good JavaScript implementation for at least 50 color pairs spanning the compliance boundaries.
Contingency: If discrepancies are found, add a configurable tolerance margin (e.g., ±0.005 on the ratio) and flag near-threshold pairs as warnings rather than hard failures, escalating to the design team for manual review.
The token manifest is a static data file. If developers add new color tokens to the design-token-provider without updating the manifest, the manifest becomes stale and the CI validator produces false negatives — passing builds that contain unvalidated color pairs.
Mitigation & Contingency
Mitigation: Add a CI step that cross-references every token constant exported by the design-token-provider against the manifest at build time, failing if any token is present in the provider but absent from the manifest. Document this requirement clearly in the contributing guide.
Contingency: If drift is detected post-merge, run a full manifest regeneration script and treat the resulting manifest diff as a blocking pull request with mandatory accessibility review.
The flutter_accessibility_lints package (or custom lint rules) may produce false positives on patterns the team deliberately uses — for example, decorative icon widgets that intentionally omit semantic labels. Excessive false positives will lead developers to add blanket ignore comments, undermining the entire lint strategy.
Mitigation & Contingency
Mitigation: Audit the full lint rule set against the existing codebase before enabling rules. Create a documented list of approved ignore-comment patterns with mandatory justification comments. Restrict ignore patterns to decorative-only contexts.
Contingency: If false positive rates exceed 10% of lint output, disable the highest-noise individual rules and replace them with targeted custom lint rules scoped to the specific patterns the team controls.