Contrast Ratios Pass, Users Still Can't Read: Audit Fixes

You've run the contrast checker. Every pair passes 4.5:1. Then a user with glaucoma squints at the screen and says, "I can't read this." That gap—between math and lived experience—is where audits go wrong.

Contrast ratios are a starting gate, not a finish line. This article looks at why the numbers fail in the field and what you can do about it.

The Auditor's Morning: Where Contrast Math Meets Reality

Contrast Ratios Pass, Users Still Can't Read

The client pulled up their dashboard, proud of the green checkmarks. Every button, every text block, every form label — all passing WCAG AA. The audit was clean. Then we sat an actual user in front of the screen, and she squinted for six seconds before saying, "I can't read this." The contrast ratio said 4.6:1. Her eyes said otherwise. That gap between the math and the moment is where accessibility audits either earn their keep or become theater.

What broke wasn't the color pairing. It was the context. The text sat on a photo — a bright sky bleeding into the background behind a light gray label. The ratio checker sampled a flat swatch, not the mess of pixels underneath. The user wasn't failing a math test. She was failing a readability test. And the audit had never asked her to try.

This happens more than you'd think. I've watched teams celebrate a 7:1 pass on a hero headline, then watch users skip over it because the font weight was thin and the line length stretched across a 27-inch monitor. The ratio doesn't know about font weight. It doesn't know about glare, or aging eyes, or a screen dimmed to save battery. It only knows two colors.

Why "Passing" Feels Like Failing

The catch is that WCAG's contrast math is a floor, not a finish line. It's a binary check on a continuous problem. A 4.5:1 ratio works fine for 12-point bold text on a white background. The same ratio on a 10-point light font over a noisy image? That's a different species of readability.

I remember a project where we fixed every flagged violation. All ratios green. Then we field-tested with five older users, and three of them misread the secondary navigation. The numbers were technically correct. The experience was technically broken. That feels like failing — because it's.

So what do you do with this? You stop treating the checker output as the deliverable. You start treating it as a starting point, then you test with real content, real backgrounds, real devices. A contrast tool can't see a gradient, a shadow, or a pattern behind your text. Only a human — or a well-designed test — can.

"The ratio passed, but the user blinked twice and moved on. That blink is the audit data I trust."

— front-end developer, after a usability session

The Typical Audit Scenario That Unravels

Most audits follow a script. You pull the palette, run the checks, export the report. Clean, fast, defensible. Then the redesign lands, and someone picks a brand color that sits at 4.4:1 against the new background — one tenth off. The designer tweaks it to 4.5:1 with a barely perceptible shift. The check passes. But the user's eyes are still doing the heavy lifting, and nobody tested whether that tenth of a point actually helped anyone read faster, scan clearer, or feel less tired.

The real audit should include a walkthrough. Put the user in front of the screen, ask them to find a price, a date, a warning message. Watch where they pause. That's your contrast data. The math is necessary, but it's not sufficient. Use it to catch the obvious failures, then use observation to catch the subtle ones.

One practical fix I've adopted: run the ratio check on the worst-case region of every background — not the average. If the text sits on a photo, sample the darkest and lightest spots. If it sits on a gradient, check both ends. Then test with font weights under 400. Thin fonts need more contrast, not the same standard. That's a pitfall the spec doesn't account for, and it's the first thing I look for now.

What usually breaks first is the note under the graph — small, gray, italicized. It passes at 4.7:1 in the checker, but on a gray background with a thin font, it's invisible to anyone over 50. The fix isn't a math tweak; it's a design decision to bump the weight or darken the shade. The audit should push you toward those decisions, not hide behind them.

Contrast Math Basics: What the Numbers Actually Say

How WCAG 2.x Computes Contrast Ratio

The formula looks precise: (L1 + 0.05) / (L2 + 0.05), where L1 is the lighter color's relative luminance and L2 the darker. Relative luminance itself is a weighted sum of red, green, and blue channels after gamma correction. Punch that into a spreadsheet and you get a number like 4.6:1, which either clears the 4.5 threshold or doesn't. Clean, objective, repeatable. That precision is exactly what makes teams trust it.

The catch is what the math leaves out. Contrast ratio assumes a user sitting still, screen at default brightness, text at full opacity, and no visual noise around the target. It also assumes the two colors are the only thing in play — no background images bleeding through, no anti-aliasing fuzz, no subpixel rendering quirks. I have watched audits pass with 5.2:1 while the actual page, on a real monitor, felt like reading wet newsprint. The ratio measures a narrow slice of visual reality, and we treat that slice as the whole pie.

The Physics of Luminance and Perception

Luminance is not brightness. Not how your eye experiences lightness. The math uses a nonlinear transfer function meant to approximate how displays emit light, then weights channels by human spectral sensitivity. Green dominates, blue barely counts. That's physics, and it's useful. But perception is messier — contrast sensitivity drops with age, with glare, with low ambient light, with screen coatings that scatter photons. Two pixels can have identical computed luminance yet look completely different on a glossy laptop versus a matte desktop panel.

The ratio also ignores font weight entirely. A 16px regular-weight gray on white might compute 4.5:1, but reading it at arm's length with dry eyes is a squint fest. Bump that same gray to bold, and suddenly it's legible — the math never knew the difference. Ambience matters too. A dark room with a bright screen creates halation around letterforms; a bright room washing out the display kills contrast that the calculator swears is fine.

Most teams skip this: the human visual system adapts. Stare at a high-contrast area, and surrounding mid-tone text feels flatter. The ratio assumes each element is judged in isolation. Real pages stack nav, cards, buttons, and body copy — all competing for the same neural bandwidth.

What the Ratio Ignores: Glare, Font Weight, and Screen Settings

Glare is the silent killer. A 6:1 ratio on paper means nothing when the office window reflects off a screen at 2 p.m. Users tilt, shade, squint — none of which the audit captures. Screen brightness settings amplify the lie. A user at 30% brightness sees a different contrast ratio than the auditor's 100% calibration. Dark mode flips everything, yet the formula doesn't care about polarity.

The practical fix is not to abandon the math but to stop treating it as a pass/fail gate. Use the ratio as a floor, then sanity-check with real conditions: bold the small text, test on a glossy panel, dim the monitor, add a glare film. What usually breaks first is not the ratio — it's the assumption that the ratio was ever enough.

Flag this for design: shortcuts cost a day.

We once shipped a "compliant" button with 4.7:1 that users called invisible. The math was right. The light in their offices wasn't.

— Front-end engineer, accessibility retrofits

Next time an audit tool flips green, ask two questions: bolded or not, and what time of day will someone read this? That's where the math ends and real legibility begins.

Field-Tested Patterns That Beat the Math

Larger type and bold weights: more forgiveness

The 4.5:1 ratio assumes a certain reading condition—normal weight, smallish text, decent eyesight. Change any of those variables and the math loosens its grip. I have rebuilt audit checklists where the fix was never darker gray; it was bolder type. A 16px regular font at 4.6:1 still makes older readers lean in. Bump that same color to 20px semibold and the complaint vanishes.

Weight matters because the eye resolves stroke thickness before it resolves color contrast. Thin glyphs at low contrast blur into a haze, especially on glossy screens. Bold strokes give the retina more signal to work with. The catch is that bold alone won't save a truly terrible pairing—yellow on white stays illegible no matter how heavy you cut it. But for borderline cases, the typographic nudge costs zero design debt.

Size does similar work. Larger type lets you drop below the WCAG AA threshold in some contexts and still pass the reading test. That sounds dangerous to auditors, but real users don't measure pixels; they measure effort. We fixed a dashboard by moving labels from 12px to 14px and kept the same contrast ratio. Support tickets about "blurry text" dropped by half.

Contrast is a floor, not a ceiling. Typography decides whether you actually live there.

— Front-end dev, mid-project review

Ambient light and screen position: the practical angles

Most audits happen in a quiet room with a calibrated monitor. Your users read on a bus, in a sunlit lobby, or under fluorescent office hum. The 4.5:1 ratio never accounts for glare. I have walked into offices where the "accessible" color scheme washed out completely because the window faced the afternoon sun.

Try this: adjust the screen's physical angle before you adjust the CSS. Sometimes the fix is a matte screen protector or reminding users to tilt their laptop. That's not an engineering solution, but it's a real one. For interface text, favor colors with a stronger luminance difference—not just ratio difference—because ambient light crushes mid-tone grays first. Pale gray on white fails outdoors even at 5:1.

The practical rule: test your palette at 60% brightness on a phone, outdoors, at arm's length. If you can't read it there, the math lied. Pair that with APCA's weighting of perceived lightness, which accounts for spatial frequency better than WCAG's simple formula. It's not perfect, but it catches the "technically passes, visually awful" cases.

Using APCA as a complementary metric

APCA—the Advanced Perceived Contrast Algorithm—doesn't replace WCAG; it supplements it. Where WCAG gives a single ratio, APCA models how contrast actually behaves across font sizes and weights. The tool spits out a polarity-aware score that penalizes dark-on-dark and rewards larger text. We used it on a client's legacy app where every pair passed 4.5:1, yet users kept squinting.

The trade-off: APCA is stricter on small light text and more forgiving on large bold. That flips some audit results. A button with white text on medium blue might pass WCAG but fail APCA at small sizes. The fix isn't darker blue—it's increasing button padding and font weight. APCA nudges you toward layout changes, not just color swaps.

Use both metrics in your report. Show the WCAG pass, then the APCA score, then the practical test. Most teams revert to checkbox audits because one number is easy to game. Two numbers force a conversation. The pitfall is over-tuning to APCA's exact scale—it's still a model, not a measurement of human eyes. But as a second opinion, it catches what the first one misses.

What usually breaks first is the assumption that one metric tells the whole story. Pair the tools, test in real light, and let typography carry the weight. Your next audit should start with font size, not color picker.

Anti-Patterns: When Teams Revert to Checkbox Audits

Automated tools are not oracles

Run Axe or WAVE on a page, and you get a clean report. Green checkmarks everywhere. Then a real user with low vision tries to read the page and fails. The tool never flagged it, because the tool only measures math — and math doesn't see the human squinting. I have watched teams ship a "passing" audit and then spend two weeks patching complaints from users who couldn't parse the layout. That gap is not a tool failure; it's a worldview failure. Contrast ratios are a floor, not a ceiling.

The trap feels logical: run the automated scan, fix every red item, export the PDF, done. That sounds fine until you realize the automated scan ignores text over images, gradients, or hover states. It misses anti-aliasing artifacts and bold weights that shrink effective contrast. And it certainly doesn't catch the button that passes at rest but turns into gray mush when a user zooms the browser to 200%. The math was right. The experience was broken.

Automated checks also can't judge context. A 4.5:1 ratio might pass on a solid background but fail on a photo with a busy sky. The tool sees a solid block of color; the human sees a white headline floating over clouds. We fixed this by exporting screenshots at three zoom levels and eyeballing every component — slow, boring, and worth it.

So the first anti-pattern is outsourcing judgment to scripts. Use them to find the obvious stuff, then turn them off and actually look.

The "just pass WCAG" trap

Teams love a checklist because a checklist ends arguments. The moment someone says "we meet AA," the conversation stops. That's the trap. WCAG AA was written as a starting point, not a finish line — but treat it as a legal standard and you optimize for the checkbox, not the reader. I've seen designers overrule a contrast fix by citing a brand guideline that demands a soft gray for secondary text. The brand wins. The user loses. Nobody reopens the case.

The catch is that compliance metrics become a shield. Product managers point to the passing audit, stakeholders nod, and the accessibility ticket closes. Meanwhile, a 50-year-old with cataracts is struggling to read the footer links. No automated scan will ever replicate that experience. You need real testers, real glare, real tired eyes — not a spec sheet.

Breaking the trap means changing the goal from "pass" to "readable." That's a bigger mandate, and some teams resist because it's fuzzy. But fuzzy beats false confidence.

Reality check: name the tools owner or stop.

Designers overruling contrast for aesthetics

Here's the messy one. A designer puts a light gray label on a white card because it looks elegant. The audit flags it. The designer argues that the label is supplementary, not essential — so the ratio can slide. And they're partially right. But supplementary often means "the thing users glance at first," like a price, a date, or a status badge. That hurts. I've reworked entire style guides because one beautiful gray failed a real-world readability test, and the redesign held up better.

Overruling contrast for aesthetics is a trade-off that never goes away. The design system wanted polish; the user wanted clarity. You can split the difference by bumping the gray from #999 to #767676 and keeping the visual weight — but that requires someone to actually test the compromise instead of defending the original choice. The fix is not banning aesthetics; it's forcing the conversation to include a person who will squint at the screen and say "no."

"The audit said pass, but my eyes said fail. So which one do I trust?"

— accessibility coordinator, post-mortem meeting

That question is the whole problem. Trust the math, but verify with vision. Next time you run an audit, add a manual pass where you zoom to 150%, dim the monitor, and step back three feet. If you can still read the page, you're ready. If not, the checklist lied — and you just found the real issue.

Maintenance and Drift: Why Audits Go Stale

Design system changes that silently break contrast

The seam always blows out in the same place. Someone updates a neutral gray from #767676 to #737373 because it looks warmer on the marketing site. The change passes visual review—two hexes apart, who notices? Then the secondary button text drops below 4.5:1 against its filled background, and every disabled input in the app goes murky. I have watched this happen three times in two years. The fix is not more vigilance. It's a hard rule: any token edit that touches color must re-run the full component contrast suite before merge. That means automated tests, not a designer squinting at a Figma frame.

The catch is that most design systems treat contrast as a property of the final rendered element, not of the token. So a palette shift passes because text-primary still contrasts fine on white. But text-primary on surface-muted? That combination was never tested. Wrong order—teams test the most visible pairs and let the long tail rot. What usually breaks first is the quiet stuff: placeholder text, focus rings over filled buttons, hover states on table rows. Nobody flags it until a user with low vision files a support ticket, and by then the drift has touched forty components.

Dark mode and OS-level contrast adjustments

Dark mode is where the math lies. A pair that hits 7:1 in light mode can fall to 3.8:1 when the same token maps to a dark surface—because your dark background is not pure black, and your text color is not pure white. The numbers are honest; the mapping is not. Most teams audit one theme and assume the other follows. It doesn't.

Then the OS steps in. Windows contrast themes, iOS increase-contrast, Android font-weight adjustments—these don't change your color values, they change how the browser composites them. Your carefully tuned 4.6:1 ratio can render as 4.1:1 under a system-level text weight bump. That sounds fine until a user with astigmatism tries to read a paragraph set in font-weight: 300. The fix is to test with OS settings flipped on, at least for the top ten components. Not every variant—just the ones that carry body copy.

An audit is a photograph, not a health check. The patient keeps aging; the photo stays flattering.

— paraphrased from a conversation with a compliance engineer who re-runs tests monthly

Re-audit cadence: how often is enough?

Quarterly sounds reasonable until your team ships twice a week. The real answer depends on where colors live. If your tokens are centralized and gated, a six-month audit might hold. If designers pick hex values in individual files—most teams, let's be honest—then you need a monthly sweep plus a pre-release check on any PR that touches a color declaration. That's not paranoia; it's math applied to human workflow.

One practical pattern: keep a tiny script that crawls the production stylesheet and flags any text/background pair that falls below the WCAG threshold for its computed font size. Run it on a cron job, post the output to a Slack channel, and make the alert part of the daily standup triage. We fixed this at a client by treating contrast failures like broken tests—not design feedback, but a build break. The first week produced forty warnings. By week three, the count was zero, because people stopped tweaking colors casually.

Most teams skip this. They audit once, celebrate, and drift. The maintenance cost is real, but the alternative is worse: a user who can't read your checkout button at 11 PM, in dark mode, with Windows contrast on. That's not an edge case—it's a Tuesday. So set the cadence, automate the check, and treat the token as the unit of truth. Your future self won't thank you—the users will, silently, by finishing the purchase.

When Contrast Math Should Take a Back Seat

Decorative vs. Functional Text: Pick Your Battles

Walk into any dashboard and you'll see the same scene: a giant hero banner with light-gray text over a busy photo, failing contrast checks, while the tiny "Save changes" button passes with flying colors. The math says the banner is unreadable. The math is right. But here's what the checker won't tell you—nobody actually reads that banner. It's branding, atmosphere, a visual rhythm setter. The user's eye slides right past it toward the actual work.

That's the trade-off most audits miss. Not all text carries equal weight. A status label that tells you your payment failed demands 4.5:1. A pull-quote that repeats the paragraph above it? Maybe 3:1 is fine. I have watched teams burn two weeks redesigning a decorative footer just to hit a ratio, while their real failure—the form helper text that disappears at dusk—went untouched. Stop treating every glyph like a legal document.

The catch is deciding which is which. Functional text is anything the user needs to make a decision, complete a task, or avoid an error. Decorative text is everything else: captions that echo body copy, background watermarks, stylistic flourishes. If you can delete the text and lose zero meaning, it's decorative. That sounds simple until you realize a site's tagline—short, punchy, sitting next to the logo—is both. It's memorable branding and a positioning statement. Pick one role and assign the stricter ratio.

Large, Short-Lived Text: Usage Overrides the Formula

Here's a scenario the WCAG math never models: a toast notification that slides in, says "Synced," and fades out in three seconds. It's small text, technically, but it's also the only thing on screen. No competing elements, no background noise, no fatigue. The user's full attention is on those six characters. Strict contrast testing flags it. Real users read it fine.

Same logic applies to large display type shown briefly—a welcome message, a progress indicator, a countdown timer. The ratio assumes sustained reading in a cluttered context. That assumption breaks when the text is big enough to be recognized at a glance or short enough to be decoded before the eye wanders. I have seen teams fix a 4.2:1 ratio on a "You're offline" banner and make it uglier in the process, chasing a number that never caused a complaint.

But careful—this loophole gets abused. "It's temporary" becomes the excuse for every low-contrast label that actually stays on the page for hours. The line is duration plus size plus isolation. If the text is below 18pt (or 14pt bold), don't use this argument. If it competes with other elements, don't use it. If users have to scan for it repeatedly, that's not short-lived—that's a pattern.

User Testing as the Final Arbiter

Numbers are shortcuts, not truth. They predict readability in controlled conditions, with perfect screens, good lighting, and young eyes. Real usage involves sun glare, blue-light filters, cracked screens, and—most importantly—people who are tired, distracted, or in a hurry. The ratio can't measure fatigue. It can't measure the cost of a wrong action. Only people can.

That's why my team now runs a five-minute readability test before any contrast debate gets escalated. We put the interface on a projector, dim the lights, and ask three colleagues to complete a task. No eye-tracking gear, no moderated lab. Just screenshots in a shared folder and honest questions: "Which text is hardest to read?" and "Where did you pause?" The results are humbling. Last quarter, a button with a 2.9:1 ratio sailed through because it was large, orange, and the only interactive element on the page. Meanwhile, a carefully compliant 4.6:1 table header got flagged by every tester for blending into the zebra striping.

Reality check: name the tools owner or stop.

The ratio is a floor, not a ceiling. It tells you when you've failed, not when you've succeeded. The user tells you that.

— field note from a client retro, after a contrast-compliant page lost three testers to a misread link

The pitfall is using human testing as an excuse to skip the math entirely. That's how you get subjective "looks fine to me" calls and inconsistent products. Run the numbers first, fix the obvious violations, then let testing override the borderline cases. The ratio should lose the argument only when the evidence is strong and specific—not because a designer prefers a lighter gray.

So where does that leave your next audit? Before you open a single accessibility checker, list every text element. Sort it into functional and decorative. Flag anything that disappears quickly or displays large. Then run the math on the functional, permanent, small stuff first. The decorative and the transient can wait for human judgment. That's not cheating—that's prioritization. And it's the difference between an audit that produces a scorecard and one that produces a page people can actually use.

Open Questions: What the Industry Still Argues About

APCA vs. WCAG: Which Metric Wins?

The old WCAG contrast formula treats every color pair as a flat math problem. It works well enough for bold black on white, but it misses how human eyes actually perceive mid-tones and saturated hues. APCA — the Advanced Perceptual Contrast Algorithm — tries to fix that by modeling spatial frequency, font weight, and even the way our pupils react to different luminance levels. The catch is that APCA is still in flux. Its thresholds shift between drafts, and browser support is essentially nonexistent. So teams face a genuine fork: adopt a perceptually smarter system that hasn't stabilized, or stick with a metric that's legally safe but visually unreliable.

I have audited sites that passed WCAG AA at 4.5:1 and still made users squint. The math said fine. The eye said no. That's the gap APCA aims to close, but it brings its own baggage — it penalizes thin text harshly and rewards bold type, which flips some long-standing design habits. Meanwhile, legal teams point to WCAG as the enforceable standard. Nobody gets sued for failing APCA. That tension won't resolve quickly, and pretending one metric is universally correct is a mistake. Choose based on your actual user base, not just the compliance checklist.

Metrics give you a starting line, not a finish line. The eye is the final judge, and it doesn't read spec sheets.

— accessibility auditor, 14 years in the field

Font Size: Does 18px Really Save You?

There's a persistent myth embedded in WCAG's large-text exception: bump the font to 18px, and your contrast ratio requirement drops from 4.5:1 to 3:1. That sounds like a free pass, but the reality is messier. Larger glyphs do fill more of the retina, which helps, but only if the stroke weight keeps up. A thin 18px font can be harder to read than a bold 14px one. The threshold exists because legibility improves with size, yet it treats all 18px text as equal — which it absolutely isn't.

What usually breaks first is the assumption that size alone compensates for low contrast. In my testing, users over 50 struggle with 3:1 contrast at 18px when the typeface is light or the screen is dimmed. The trade-off is real: forcing a 4.5:1 ratio on large text shrinks your design palette and drives teams toward dark-on-light monotony. But the alternative — trusting the exemption — risks excluding a significant chunk of your audience. A pragmatic middle ground: keep 3:1 for bold 18px+, but require 4.5:1 for regular weight at any size. That's not a spec, just a sensible heuristic.

Should We Measure on the User's Device?

Every contrast audit happens on a calibrated monitor in a controlled room. Your users read on OLED phones in sunlight, on flickering office screens, on laptops with blue-light filters cranked to maximum. The gap between lab conditions and real-world viewing is enormous, and yet the industry keeps pretending one number applies everywhere. Some argue we should shift to device-based measurement — sampling the actual display output via screen APIs or user-reported settings. That sounds progressive until you consider the chaos: every device would produce different results, making compliance impossible to standardize.

The industry still argues about this because both camps have valid points. Measurement on the user's device would reflect lived experience, but it would also break reproducibility. You can't file an audit report that says "depends on the phone." That said, ignoring device variance entirely is equally flawed. One practical compromise: run a secondary check for common conditions — brightness at 50%, a warm color filter enabled, a glossy screen. It won't give you a single pass/fail, but it will surface edges cases that pure desktop testing misses. The debate won't settle soon, and that's okay — the discomfort is what keeps the methodology honest.

So What's Next? Experiments for Your Next Audit

Run a five-user field test with real devices

Stop auditing in a dark room with a calibrated monitor. That's not where your users live. Take five people, give them your actual product, and send them outside. Or into a bright kitchen. Or onto a train with smudged screens. I did this last quarter with a client whose dashboard passed every automated check at 4.5:1. Out in daylight, two users couldn't read the secondary labels at all. The math was right. The physics of glare and phone glass won anyway.

Keep the test brutally short. Ask each person to complete one task, then note where they pause. Don't coach them. Don't explain the contrast ratios. Just watch which elements make them squint. The catch is you'll see failures that no checker will ever flag—things like grey-on-white in direct sunlight, or thin fonts that blur at arm's length. Those failures are real. Fix those first.

Record the 'just readable' threshold

Your contrast checker gives you one number. Users give you a range. Next audit, try this: darken a text color until someone says "that's uncomfortable," then stop. That's their threshold. Now compare that across five people. You'll find the range is wider than the guidelines suggest. Some folks read comfortably at 3.8:1 on a good screen. Others need 7:1 even indoors. That gap is where your design decisions live.

Write those numbers down. Keep a small chart of what failed and what merely annoyed. Over time, you'll build a sense for when the standard is too lenient and when it's overkill—say, for large headings or decorative text that nobody actually reads. The pitfall is turning this into a personal preference contest. Avoid that. The goal is a threshold you can defend with evidence, not taste.

Track contrast drift over a quarter

Audits go stale because teams change colors casually. A button tweak here, a background shift there—six weeks later, the palette quietly fails. Set a calendar reminder once a month. Screenshot your top ten components. Check the actual rendered colors, not the design tokens. That's how drift sneaks in, via overrides and quick fixes that never get documented.

Most contrast failures aren't designed. They're accumulated—one careless edit at a time.

— lead designer, post-drift post-mortem

Use a simple script to extract computed styles from your live site. Compare against last month's values. Flag anything that moved more than 0.2 in relative luminance. That's a cheap, automated tripwire. The real work is deciding whether each change matters. Most won't. But the one that does—say, a hover state that drops below legibility—gets caught before it ships. That saves you a support ticket and a user who couldn't read the price.

What usually breaks first is the "temporary" color. Someone adds a status badge in a hurry. It ships. Nobody audits it. A quarter later, it's part of the brand. Now you're stuck defending a mistake as a feature. The experiment forces you to notice. That's the whole point—not perfection, just awareness.