COLOR-05
Inconsistent button/link colors across the site
What the check measures
Across all pages in the sample we collect the colours of elements the module recognised as accent or link (that is, buttons and links) and count how many distinct ones there are. The finding is raised above 6 (config/).
It is the only finding in the colour module that looks at the site as a whole, not at an individual page. It therefore appears at most once in the report and has no specific page attached.
What the check does not do: it does not distinguish deliberate gradation (primary and secondary buttons rightly differ) from randomness, it cannot see states (hover, active, disabled), and it cannot see colours on pages outside the sample. The finding is site-level and informational.
How strong the evidence is
We recommend it because it does no harm or has some other benefit, but we promise nothing about whether it makes language models cite you. Nobody has demonstrated that yet.
For visibility in AI answers there is no effect at all, and no backing in any standard either. The threshold of 6 is our convention from practice, marked as a proposal pending revision.
What it is about: whether a visitor learns what is clickable on your site. When a button is one colour on one page and another elsewhere, they have to make that judgement afresh each time. It is not a barrier, it is a tax on attention.
There is an indirect accessibility connection, even though our finding does not measure it: inconsistent link colouring raises the odds that somewhere you rely on colour alone and elsewhere on an underline. And that is COLOR-03 and WCAG 1.4.1.
When to ignore it: when you have a designed system in which the primary action is one colour, the secondary another, the destructive a third, an in-text link a fourth, with variants in a dark theme: you get past six easily and it is fine.
When to look: when you designed no such system. Then seven button colours mean seven decisions made by different people that nobody reconciled.
How to fix it
This is not fixed page by page but by a decision. A process that works even on a large site:
- Define roles, not colours. Primary action, secondary action, destructive action, in-text link. Four is usually enough.
- Assign one colour per role and record it as a CSS variable.
- Walk the site and remap existing buttons onto roles. This is usually where you discover that three different blues meant the same thing.
- For the colours left over, ask whose they are. They tend to be third-party components: an embedded form, a chat widget, a payment button. Those can often be styled; nobody ever tried.
:root {
--btn-primary: #225473;
--btn-secondary: #5b6470;
--btn-danger: #b3261e;
--link: #225473;
}- Derive states from the role colour, not from a new colour; darken or lighten the same value.
- Check the contrast of every new pair (
COLOR-01). Consolidating a palette is the cheapest moment to do it in one pass. - Do not forget the dark theme, if you have one. The roles stay, the values change.
What the report says about it
Finding description
Buttons and links across the sampled pages use [the count] different colors combined, above the indicative threshold of [threshold]. This is NOT an accessibility failure and has NO documented effect on AI search visibility. It's only a signal that the site's visual language may be inconsistent across pages.
Recommendation
Consider standardizing the primary button color and the link color to one (at most two) design-system values across the whole site. It makes interactive elements easier for visitors to recognize.
Sources
- W3C WAI: Use of Color, WCAG 1.4.1 (accessed 2026-09-12)
Text verified 2026-09-12