COLOR-04

High number of distinct hues on the page

InfoAccessibility

What the check measures

A palette is built from the colours actually present on the page; very similar shades are merged into one, so that shades produced by font anti-aliasing are not counted. The finding is raised when there are more than 12 distinct colours (config/colors.json#colorCount.too_many_threshold).

The merging uses distance in a perceptual colour space with a threshold deliberately more permissive than the limit of distinguishability for an untrained eye. Two colours must be noticeably different to count separately.

What the check does not do: it does not judge whether the palette makes sense (12 colours from one designed scale is better than 8 arbitrary ones), it does not count colours inside images, and it does not separate content colours from interface colours. The finding is page-level and informational. It costs no score at all.

How strong the evidence is

Effect not demonstrated

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 none for ranking either. And this time there is no backing in a standard either: no specification says how many colours a page should have.

So of all the paid-module codes this is the finding with the weakest backing of any, and it is fair to say so plainly: the number 12 is our convention from practice, nothing more. It is marked as a proposal pending revision and it exists because a high number of shades tends to be a symptom, not a defect.

A symptom of what: a site where styles accumulated across eras, people or third-party components. Each layer brought its own blue. The result harms nobody; it is just harder to maintain and looks less coherent.

When to ignore it without guilt: if your site has a designed palette and it has fifteen shades, that is fine. If the page has strongly coloured content (charts, photo galleries, category tags), a high number is to be expected.

When to look closer: when the number surprises you. That usually means there are colours on the page you do not know about. And those often belong to something that should no longer be on the site.

How to fix it

This is tidying, not repair, and it pays off only when you are going to touch the styles anyway. The report prints the palette, so step one is to look at what is in it.

  1. Sort the colours by role, not by hue: text, background, border, accent, states. Most sites get by with two or three shades per role.
  2. Find the near-identical pairs. Two greys differing by a few percent are almost always a mistake, not a choice. Merge them.
  3. Name the resulting palette with CSS variables and take new colours only from it.
  4. Look at what is left over. A colour you cannot assign after sorting usually belongs to a component that has no business being on the page.
:root {
  --ink: #1a1d21;
  --ink-soft: #5b6470;
  --ground: #ffffff;
  --surface: #f5f7f9;
  --line: #dfe4ea;
  --accent: #225473;
  --ok: #1f7a4d;
  --warn: #a66300;
  --crit: #b3261e;
}

And something worth doing at the same time, because unlike the colour count it has hard backing: check the contrast of every text–background pair (COLOR-01). Consolidating a palette is the cheapest moment to put that right in one pass.

What the report says about it

Finding description

After quantization (merging visually near-identical hues) the page uses [the count] distinct colors, 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 rough signal about visual design consistency.

Recommendation

Consider narrowing the palette to a smaller design-system set (base, accent, status colors). A more consistent look tends to read as more coherent and trustworthy, though that isn't guaranteed on its own.

Sources

Text verified 2026-09-12