Denshin / Blog / Design
Our brand colour failed contrast, so it got a darker sibling
Our bronze accent measured about 2.5 to 1 on cream, well short of WCAG AA for text. We kept the colour and added a darker ink token for text on light grounds. What changed, what stayed bright, and what still fails.
Denshin Team · Design & Engineering · 17 October 2026 · 3 min read
Our accent colour is a warm bronze, #c78c55. It turns up all over this site: the small uppercase labels above headings, the index numbers on lists, emphasised words in headlines, the active link in the nav. It looks good. On the cream background we use for light sections, it is also hard to read for a lot of people.
We measured it properly in July 2026, during an accessibility pass on the redesign, the same stretch of work in which the homepage got a static version for people who prefer reduced motion. Bronze on cream comes out at about 2.5 to 1. WCAG AA asks for 4.5 to 1 for normal text and 3 to 1 for large text, so it failed both. And it failed everywhere, because the pattern had been copied into every light section of the site. It was not one bad component. It was a habit.
Two bronzes
The obvious fix, darkening the brand colour, would have changed the dark sections too, and bronze on our near black background was fine at about 6.5 to 1. So rather than one colour we now have two tokens:
--bronze, the original #c78c55, for bronze text on dark backgrounds and for things that are not text.--bronze-ink, #8a5622, for bronze text on light backgrounds. About 5.2 to 1 on cream.
Side by side they read as one colour family, which was the point. Nobody had to reopen the brand guide.
The ink version only works one way round. On the dark background it drops to about 2.4 to 1, worse than the problem we started with. That matters because several of our classes are used on both grounds: the same eyebrow label sits on a dark hero on one page and a cream panel on another. Those classes are scoped by their light parent, so a rule along the lines of .panel--paper .eyebrow switches to ink while the default stays bright. It is a little more CSS than we would like, and a lot less than maintaining two sets of components.
What stays bright
Non-text elements have a different bar. WCAG 1.4.11 asks for 3 to 1 for user interface components and graphics that carry meaning, and purely decorative marks have no requirement. Hairlines, decorative borders, the small SVG marks and the large blended wordmark in the hero all kept the bright bronze. If you do this exercise yourself, look hardest at the non-text elements that are functional, like input borders and focus indicators, because those are the ones where 3 to 1 is a real requirement and not a nice to have.
What we have not fixed
A handful of places still sit below AA, and we know which: some bronze text on dark backgrounds that is also dimmed with opacity, a couple of numerals in menus and breadcrumbs, and one hover state where cream text sits on a bronze fill. They are on the list. We would rather say that plainly than claim a clean audit.
If you own a brand colour
Check it as text on every background you actually use. Not on white, and not on the swatch in the brand guide. A colour can pass comfortably on one ground and fail on the next, and contrast is a property of the pair, not of the colour.
If it fails, a darker text variant of the same hue usually solves it without a conversation about changing the brand. Then put the rule in the token's name. --bronze-ink tells the next developer what it is for. A note in a design file does not get read at six in the evening when someone is adding a label in a hurry.
Tags: Accessibility, WCAG, Colour Contrast, Design Tokens, CSS
All posts · Work with Denshin