The Helmholtz-Kohlrausch Effect: Why Your Saturated UI Colors Look Brighter Than They Should

Open any contrast-checking tool and punch in a vivid, fully saturated red, say hsl(0, 100%, 50%), against a dark gray background. The tool greenlights it: the luminance ratio clears WCAG AA with room to spare. Now squint at the actual screen. The red button doesn't sit flat on the background. It glows, almost radioactively, and looks far brighter than a neutral gray with exactly the same measured lightness.

You're not making it up. You're seeing the Helmholtz-Kohlrausch effect, a perceptual effect described in the 19th century that quietly breaks today's accessibility math.

Named after Hermann von Helmholtz and Friedrich Kohlrausch, it describes how highly chromatic (saturated) colors look brighter than achromatic colors of the same luminance. Your eyes are working normally. Contrast-ratio formulas were simply never designed to handle this. As design systems rely more on programmatic contrast checks and automated accessibility audits, the gap between measured lightness and perceived brightness is causing real failures that slip past every tool in the pipeline.

Below: the science, what it means for UI design, and the strategies people are starting to use to compensate.

A 19th-century discovery with modern consequences

Helmholtz first observed in the 1860s that spectral colors appeared brighter than white light of equal luminance. The finding didn't fit neatly into the physics of the time. Decades later, in the 1930s, Friedrich Kohlrausch measured it in psychophysical experiments, establishing that the "brightness bonus" varied systematically with wavelength and saturation.

Here's the mechanism. The human visual system processes chromatic and achromatic signals through separate neural channels. This is the opponent-process theory of color vision. Highly saturated colors stimulate both the luminance channel and the chromatic channels simultaneously. Your brain adds these signals together, producing a perception of extra brightness that has no physical basis in the light's measured intensity.

The effect is wavelength-dependent. Reds and blues trigger the strongest H-K boost, with perceived brightness increasing by up to a factor of 2x compared to an equiluminant gray. Yellows and greens, which sit closer to the luminance peak of human vision (around 555 nm), show a much smaller effect. A vivid cerulean blue can look twice as bright as the photometer says it should, while a saturated gold barely changes.

For anyone building interfaces, the important part is that this boost is invisible to any formula based only on photometric luminance (cd/m²). Luminance measures the achromatic channel alone. The extra brightness from color exists only in perception, and no amount of pixel math will catch it.

Loudness in audio is a useful comparison. Two sounds at the same decibel level can seem different in loudness depending on their frequency content, because your ear's sensitivity varies with frequency. The H-K effect is the visual version: the instruments measure the decibels, while your eyes hear the whistle.

How contrast formulas get it wrong

WCAG 2.x contrast ratios are computed from relative luminance, derived from a linear-light weighted sum of R, G, and B. The sRGB luminance formula looks like this:

Y = 0.2126R + 0.7152G + 0.0722B

There's no saturation term. The formula can't tell a vivid red from a desaturated pink of equal luminance, so to the algorithm they're equally bright.

Here's a concrete example. A saturated red (#FF0000) and a medium gray (#7C7C7C) both yield a relative luminance near 0.21. Place both against a #1A1A1A dark background, and they produce contrast ratios around 4.8:1. By the numbers they're identical, but the red looks far louder than the gray. The H-K effect opens a gap in perceived brightness that the formula misses entirely.

What about APCA, the Accessible Perceptual Contrast Algorithm and candidate metric for WCAG 3.0? APCA improves on WCAG 2.x in several ways: polarity sensitivity, spatial frequency awareness, and better modeling of the human contrast sensitivity function. But as of its 2026 specification drafts, APCA still derives its lightness contrast from luminance without a chromatic correction factor. The H-K gap is still there.

This cuts both ways. Automated checks can approve pairings that produce glowing text, which some users find harder to read. They can also fail high-saturation pairings that are perfectly legible. The formula is confidently wrong in both directions.

The glowing red button

The easiest way to see the H-K effect is a side-by-side comparison. Place a call-to-action button in saturated red (#FF0000) next to an identical button in equiluminant gray (#7C7C7C), both on a dark charcoal background (#1A1A1A). Despite sharing the same luminance value, the red button appears to float above the surface, almost self-illuminated.

It isn't limited to red. A saturated electric blue (#0055FF) on dark gray glows in the same odd way, sometimes more strongly. A saturated yellow (#FFD700) on the same background gets a much smaller boost. Because the wavelength dependency is consistent and predictable, you can design around it.

It causes problems in plenty of real interfaces:

• Vivid red error states on dark mode backgrounds can make error messages look like they're pulsing, which draws too much attention and adds visual stress.
• A bright red notification badge on a dark nav bar seems to hover in front of the surface, an unintended depth cue.
• Saturated blue links in a dark reading mode can shimmer against the text and pull focus away from the content.
• Saturated hues on a dark chart pop unevenly, so some data series look more prominent than others for reasons that have nothing to do with the data.

Light backgrounds behave differently. The same saturated red on white doesn't glow in the same way, because the surrounding luminance is high and the contrast works differently. The H-K effect does the most damage in dark mode, which is exactly where modern design systems are putting the most effort.

Measuring it: Fairchild and Pirrotta's H-K correction

If the effect can be measured, can a formula correct for it? Sort of.

The most widely cited compensation model comes from Mark Fairchild and Erwin Pirrotta, published in 1991. Their model adjusts perceived lightness based on a color's CIE chromaticity coordinates. The correction factor can increase a color's effective lightness by 20% to 100% depending on saturation and hue angle. A fully saturated blue might need its apparent lightness nearly doubled to match what your eyes actually see.

The formula works in three steps. First, it takes a color's position in CIE u'v' chromaticity space. Second, it calculates the color's distance from the achromatic point, which serves as a proxy for saturation. Third, it weights that distance by a hue-dependent function that peaks around blue and red, producing a multiplier on the luminance factor Y. The result is an adjusted lightness value that better predicts what humans actually perceive.

Yoshinobu Nayatani proposed an alternative model in 1997 that integrates more directly with CIECAM color appearance models. That makes it an easier route to corrections that could, in principle, be built into future contrast algorithms, since CIECAM-based systems already model viewing conditions, adaptation, and surround effects.

Both models have real limits, though. They were derived from laboratory experiments with uniform color patches, not complex UI layouts with varying text sizes, anti-aliased edges, surrounding color contexts, and subpixel rendering. Spatial frequency matters a lot: a thin saturated red line produces a different response than a large saturated red button. The models point you in the right direction without giving you an exact answer.

Practical strategies for designers and engineers

Here are seven things you can do about it now.

1. Desaturate accent colors in dark mode

Instead of using a pure hue at full saturation, pull chroma down 20-40% for high-H-K hues like reds, blues, and magentas. That reduces the brightness boost without losing the color's identity. Google's Material Design 3 tonal palette system already pushes designers this way: its dark-mode tokens favor less saturated variants of each primary and secondary color, and this is why.

2. Adjust lightness targets asymmetrically

When defining your design system's contrast targets, build in a "saturation penalty" for vivid accent colors. If your neutral text passes at L*=60, a saturated red text might need to target L*=50 or lower to produce equivalent perceived contrast against the same background. The asymmetry feels counterintuitive, but it matches how your users actually see the interface.

3. Trust the squint test alongside the algorithm

Add a manual QA step where reviewers evaluate high-saturation pairings on actual screens, not just in Figma or browser DevTools. Squinting reduces spatial detail and emphasizes luminance perception, making H-K distortions more obvious. If a color element appears to "jump off the page" when you squint, the H-K effect is probably in play, regardless of what the contrast checker says.

4. Advocate for H-K-aware tooling

A few experimental tools and libraries are starting to include chroma-adjusted lightness. The Color.js library, maintained by Lea Verou and Chris Lilley, provides hooks into CIECAM02/16-based color spaces where an H-K correction could be applied. Some prototype Figma plugins have started experimenting with saturation-aware contrast warnings. Ask your tool vendors to add these corrections. The more designers ask, the sooner it happens.

5. Be especially cautious with saturated text on dark backgrounds

The H-K effect makes saturated colored text appear to "bleed" or shimmer, reducing legibility even when contrast ratios pass. It's worst with thin fonts at small sizes. For body text, always prefer desaturated or near-neutral tones. Reserve full saturation for large decorative elements, hero banners, or icon fills where legibility of fine detail isn't the primary concern.

A related optical effect makes this worse: halation, sometimes called "bloom," where a highly saturated color appears to bleed outward slightly and soften the edges of letterforms. It isn't the H-K effect itself, but the two tend to turn up together and compound the legibility problem. If saturated text is unavoidable, aim well above the minimum contrast ratio rather than just clearing it.

6. Test on wide-gamut screens

The H-K effect is more pronounced on wide-gamut displays (P3 and beyond) because they can reproduce more saturated colors than sRGB monitors. A pairing that behaved well on a calibrated sRGB monitor can become noticeably more vivid on a recent phone or laptop. Check high-saturation pairings on the actual devices your users carry.

7. Add a neutral buffer

Instead of placing saturated text directly on a contrasting surface, put a neutral-toned container, outline or background chip behind it. That gives the eye a local reference point and reduces the brightness confusion. A near-white pill behind a vivid coral label, for example, anchors the color and calms the glow.

The bigger picture: why perception-first design matters

The H-K effect is one of a family of perceptual effects that luminance-only metrics fail to capture. The Bezold-Brücke shift causes hue to change with intensity. The Hunt effect causes colorfulness to increase with luminance. Chromatic adaptation causes your visual system to recalibrate its white point based on the ambient environment. Together they add up to a consistent gap between color as numbers and color as people experience it.

Accessibility standards are gradually moving toward perceptual models, with APCA and CIECAM-based appearance models both steps in that direction. Full integration of chromatic appearance effects into automated tools is likely still years away. The research exists; the standardization and tooling don't, yet.

Until then, designers and front-end engineers can't hand perceptual judgment over to algorithms. Understanding effects like H-K is what turns a technically compliant interface into an accessible one. Compliance is the minimum. The real test is whether a person on a real screen, in a real room, can comfortably use what you built.

Trust your eyes

Human vision isn't a photometer. Your eyes and brain don't passively measure light. They interpret it through layers of neural processing that no single formula has fully captured yet.

If you build dark-mode interfaces, saturated brand systems or accessible data visualizations, the numbers are necessary but not enough. A saturated red that passes contrast checks can still glow and hurt readability in ways the math never predicted.

Keep your automated tools, but learn their blind spots. Look for what the algorithms miss, compensate with desaturation and lightness adjustments, and push for perception-aware tooling. That's how you close the gap between measured compliance and real-world legibility.

The next time a vivid accent color looks suspiciously bright on your dark canvas, don't dismiss it. Your eyes are telling you something the formula missed.