Checking a chart in greyscale belongs in design review, since fixing it after launch costs far more

What it is

Greyscale checks, CVD simulation, and de-colour tests must run inside the design review, not surface later through user feedback. The reason is mechanical: remediation cost climbs exponentially by stage — swapping an encoding at mock stage changes a few parameters; after development it touches data structures, component interfaces, and test suites; after release it costs user attrition and compliance exposure. Accessibility defects are the most expensive of the three because they are systemic coverage failures, not isolated experience issues.

Why it happens

Colour encoding permeates the whole implementation chain: the palette determines the data mapping, the mapping determines component interfaces, and the interfaces determine test cases. At design stage the defect is parameter-level; the same defect in development is interface-level; in production it is migration-level — each step multiplies the fix by the entire downstream. Meanwhile the verification itself is nearly free: simulation and greyscale conversion are minute-scale operations that catch the most expensive defects at the cheapest moment. Late verification is not a diligence problem — it is two operations whose costs differ by orders of magnitude.

Where it stops holding

Design-time verification is not a universal gate either: simulation tools cannot see implementation-level contrast fallback, theme switching, or dark mode, which need retesting at development acceptance; and real-reader testing is never fully replaceable by simulation, so high-stakes surfaces still warrant a sampled panel. The principle is "each stage owns its own failure surface": design owns encoding and substitutes, development owns implementation fidelity, release owns real-user feedback — skip any layer and defects leak through that layer's seam.

Applying it

• Write the three checks (greyscale, CVD simulation, de-colour test) into the design review checklist as release conditions for chart deliverables; no execution, no handoff to development.
• Add two items to development acceptance: re-run greyscale and simulation on implemented screenshots, and retest contrast under dark mode.
• Verification: sample the last three months of chart defect tickets — if every "colour-only information" issue was caught at design review, the gate is working; if they appear post-development or in production, trace back to which stage skipped its check.

Related

• Same group: U4.05.1 Print, glare, and colour deficiency all strip colour · U4.05.2 Lightness, shape, pattern, and direct labels are colour's main substitutes · U4.05.3 Colour should reinforce, never solely carry, information · U4.05.4 Colour-only status cues fail accessibility requirements
• Nearby: U4.04.3 Must remain readable in greyscale · U10.04.6 Run the checklist before publishing, not after being challenged
• Search terms: shift left accessibility · design review checklist · colour audit