Designing Accessible Color Systems That Still Look Intentional

A common complaint we hear from clients after their first pass at accessibility remediation is that the product now looks 'washed out' or 'boring,' because someone ran every color through a contrast checker and desaturated anything that failed. That's a real risk: contrast compliance and visual intent can pull against each other if you treat accessibility as a final pass instead of a constraint built into the palette from the start.
Our approach now is to build color systems in a perceptually uniform space, generating tints and shades from a small set of base hues so that contrast ratios are predictable at every step rather than discovered after the fact. When a brand hue is too light to pass 4.5:1 against white at normal text sizes, we don't just darken it randomly, we find the point on that hue's curve that passes while staying recognizably 'on brand,' which usually means adjusting lightness and chroma together rather than flattening saturation.
We also stopped relying on color alone to carry meaning anywhere it mattered functionally, status badges, form validation, chart legends, because color-only signaling fails not just color-blind users but anyone in bright sunlight or on a degraded screen. Every status color in our systems now pairs with an icon or text label. This turned out to help everyone, not just users who needed it, because glanceable icon shapes are faster to parse than color alone even for people with typical vision.
For data visualization specifically, we build categorical palettes that stay distinguishable when converted to grayscale, which forces enough lightness variation between adjacent colors that they also tend to be more distinguishable for color-blind users. We test this by literally desaturating the palette during design review, not after handoff.
The result, on a healthcare client's patient portal redesign, was a palette that passed AA across the board and that the client's own brand team said looked more considered than the pre-redesign version, not less. Constraints handled early tend to produce better design decisions than constraints bolted on at the end.


