critical priority low complexity backend pending frontend specialist Tier 1

Acceptance Criteria

The manifest color_pairs section contains entries for every foreground/background combination used in any of the four organisation themes (NHF, Blindeforbundet, HLF, Barnekreftforeningen).
Every entry with text_size_category='normal' has contrast_ratio ≥ 4.5 and wcag_level='AA' or 'AAA'.
Every entry with text_size_category='large' or 'ui_component' has contrast_ratio ≥ 3.0 and wcag_level='AA' or 'AAA'.
A Dart unit test iterates all color_pair entries from the manifest and asserts the contrast_ratio meets the threshold for its text_size_category — this test serves as a living compliance gate.
The manifest includes at least the following critical pairs for all four themes: primary button text on primary background, body text on surface background, placeholder text on input background, disabled text on disabled background, error text on error background.
No color pair in the manifest has a contrast_ratio < 3.0 — any such pair causes a build-time assertion failure.
The manifest file is committed to version control with a clear commit message referencing WCAG 2.2 SC 1.4.3 and SC 1.4.11.

Technical Requirements

frameworks
Flutter
Dart
data models
AccessibilityTokenManifest
ColorPairEntry
performance requirements
The compliance unit test must complete in < 1 second

Execution Context

Execution Tier
Tier 1

Tier 1 - 540 tasks

Can start after Tier 0 completes

Implementation Notes

Use the WCAG 2.2 relative luminance formula to compute contrast ratios for each color pair before populating the manifest — do not estimate visually. A utility script (scripts/check_contrast.dart) is recommended to automate the computation: it reads the raw hex values from the design token source files, computes contrast ratios, and outputs the manifest entries. This script does not need to be production code but should be committed for future use. When covering all four organisation themes, note that Blindeforbundet has the most demanding accessibility requirements (screen reader users) and should be audited first.

Disabled state color pairs typically fall below 3:1 intentionally — per WCAG 2.2 SC 1.4.3 exception, disabled components are exempt; document this exemption in the manifest entry with a 'wcag_exemption' field rather than omitting the entry.

Testing Requirements

The primary test artifact for this task is the compliance gate test: a flutter_test unit test that loads the manifest, iterates every ColorPairEntry, and asserts contrast_ratio meets the WCAG 2.2 AA threshold for its text_size_category. This test must be added to the CI pipeline and must fail the build if any entry falls below threshold. Additionally, write a test that asserts the total number of color pair entries is ≥ a defined minimum (e.g., 20) to prevent accidental truncation of the manifest during future edits.

Component
Accessibility Token Manifest
data low
Epic Risks (3)
high impact medium prob technical

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.

medium impact high prob scope

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.

medium impact medium prob dependency

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.