Contrast cannot be signed off on mockups; it must be verified on rendered pixels

What it is

A mockup swatch is intent; a framebuffer pixel is contrast. Opacity, shadows, background images, browser-default appearance, and OS filters all rewrite the two colours. Rendered contrast requires sampling the layer the user sees, not the stylesheet or the artboard chip.

An icon that calculates to 3.2:1 on the canvas, then sits under an 80% white veil and a ring of anti-aliasing, can drop its edge pixels below the bar. Passing the file is not passing the screen.

Why it happens

Colour is rewritten several times down the pipeline. The stylesheet holds an sRGB intent; compositing multiplies alpha, stacks the result on a photo or gradient, then a translucent box-shadow spreads along the edge. A one- or two-pixel stroke is mixed with its neighbour by anti-aliasing, so the eyedropper often hits a blend, not a chip. Night Shift, true-tone, forced colours, and hardware P3-versus-sRGB conversion split the computed value from the seen value.

If a form control still uses platform appearance, the mockup border is never painted — the engine’s border is. A contrast tool that reads CSS computed colour is reading a number that never became a pixel.

Studying it

Use an eyedropper or a tool that captures the composited result. Sample rendered pixels, and log three columns: artboard chip, CSS computed value, pixel value. Isolate translucent stacks, shadow edges, 1 px strokes, and system-default controls as drift-prone cases.

Independent variables: alpha, blend mode, background complexity, whether OS colour temperature or forced colours is on. Dependent variables: the gap among file ratio, computed ratio, and pixel ratio; how often the gap crosses the threshold.

WCAG-EM sampling should take pixels once per target browser and appearance (light / dark / high contrast), not once inside the design file’s plugin. APCA is equally meaningless if it is fed chips rather than rendered colour.

Where it stops holding

Large, opaque, unshadowed, un-photographed blocks usually match between file and screen; re-sampling them pays little. Video frames, canvas animation, and WebGL contrast change over time; a single frame does not stand for the clip. Print styles and ebook exports do not use this screen pipeline. A colour-vision simulation filter placed before the eyedropper rewrites the pixels a second time and measures the filter, not the product.

Applying it

• Put contrast sign-off on the composited result in a real browser or device: sample pixels in light, dark, and system high contrast. Do not only run a design-file plugin.
• Treat translucent text and icons as the mixture after stacking; on a photograph, sample both the lightest and darkest regions the graphic sits on.
• Native forms, third-party widgets, and shadow strokes — pixels the mockup may not contain — must be measured on the implementation.
• How to check: walk a primary path and eyedrop every icon, border, and state indicator on the rendered pixel. Where the file passes and the pixel fails, the pixel wins; then trace whether alpha, a neighbour, or system appearance caused the drift.

Related

• Same group: J2.10.1 Icons, borders and state indicators must meet a contrast threshold too · J2.10.2 Unchecked checkbox and input borders are the most often-missed low-contrast elements · J2.10.3 Visual information that changes on hover or focus must keep the same contrast
• Nearby: J2.01 Text Contrast · J2.15 Dark Mode and High Contrast Compatibility · J5.08 Limits of Automated Checking
• Search terms: rendered contrast · composited colour · eyedropper contrast