Links you can only find by colour

What a colour-only link costs your store

Somewhere in your delivery page there is a sentence like “full measurements are on the size guide”. Three of those words are a link. You know that because they are a slightly different colour — perhaps a restrained blue-grey the designer chose because bright blue felt loud. Strip the colour away, and nothing is left. No underline, no border, no shape. The sentence reads as plain text, and the size guide might as well not exist.

Colour is stripped away more often than design reviews assume. Around one man in twelve and one woman in two hundred has some form of colour vision deficiency, and the most common forms compress exactly the region most link palettes live in — blues, purples and greys drift towards one another. A shopper with low vision runs the screen at double zoom with brightness down, and subtle hue differences flatten out. A phone in July sunlight renders your careful blue-grey and your body-text charcoal as the same colour. An older laptop panel was never going to tell them apart in the first place.

WCAG 1.4.1 Use of Color (Level A) is the criterion: colour must not be the only visual means of distinguishing a visual element. For links inside prose, the W3C documents the failure explicitly — F73, “creating links that are not visually evident without color vision” — and the practical damage on a shop is concrete. The customer cannot find the size guide, so they guess the size, and the order comes back as a return. They cannot see that “delivery exceptions apply” is a link, so the exception surprises them at the door. The information was there. It was just encoded in a channel some of your customers do not receive.

The standard permits a colour-only link under narrow conditions — technique G183: a 3:1 contrast ratio between link colour and surrounding text, plus an additional cue on hover and focus. It is a legitimate route and a fragile one: the ratio has to hold for every text-and-link pairing on the site, the hover cue does not exist on touch, and one theme update can break the arrangement silently. The underline is the boring, durable answer, which is why it is the one browsers have shipped as a default since the beginning.

How it is detected here

axe-core 4.12 carries a neighbouring rule for this criterion, link-in-text-block, which approaches it through colour: where a link inside a block of text is distinguished only by colour, the rule tests that colour against the 3:1 threshold, and where it cannot compute the colours it returns the element for review rather than a verdict. That rule runs in the scan, but it is not what this family is keyed to.

The deciding detector is Klarvo’s own probe, klarvo.content-link-underline, which runs in a real browser against the rendered page and asks the sturdier question directly: does each content link carry a persistent non-colour cue at rest? The probe is deliberately bounded:

• It looks only inside authored content containers — main, article, .entry-content and .wp-block-post-content — because that is where a link sits inside sentences and needs to be told apart from them. Navigation menus, headers and footers are excluded: their links are identified by position and grouping, not by colour against prose.
• For each link it reads the computed style and accepts either cue: a text-decoration-line that includes an underline, or a visible bottom border. Either is a shape a colour-blind reader can see.
• Links styled as buttons — anything matching .button or .wp-element-button — are excluded. A filled, bordered button is its own affordance and needs no underline.

Every link in scope with neither cue is counted, and the count is attributed to the exact page it was observed on. The probe detects precisely the family the fix below can repair, and no more than that: passing it does not by itself establish every use-of-colour condition on the page, and the report never pretends otherwise.

What Klarvo does about it

This family is auto tier. The fix is not generated per element and not guessed at per site: it is a constant, pre-audited CSS profile, the same reviewed rule for every store, applied server-side in the HTML your store serves — never painted on by a script in the visitor’s browser. This is what ships:

:where(main, article, .entry-content, .wp-block-post-content)
  a:not(.button):not(.wp-element-button) {
  text-decoration-line: underline !important;
  text-decoration-thickness: max(1px, 0.08em) !important;
  text-underline-offset: 0.15em !important;
}

Three deliberate choices are folded into those lines. The scope matches the probe exactly, so the fix repairs precisely what was detected and touches nothing else — your navigation, your buttons and your header stay as designed. The thickness and offset keep the underline a tuned hairline that scales with the type and clears descenders, rather than the heavy strike-through look that gave underlines a bad name. And the declarations are marked !important because the failure being fixed is a stylesheet rule — usually a { text-decoration: none; } in the theme — and the repair has to outrank the rule that caused it.

The profile is injected once, in a style block with a reserved id, and the operation is idempotent: a page already serving the profile never receives a second copy. Your own colour choices are untouched — the link keeps its hue; it gains a shape.

Then the claim is checked rather than assumed. The page is fetched fresh and the served HTML must actually contain the profile before the fix is recorded as applied, and the probe runs again in the browser lane on the next scan, where the count of undecorated content links on that page should read zero. An automated finding is evidence, not a certificate — and so is an automated fix, which is why it is re-validated instead of trusted.

How to fix it yourself

The theme-level fix is one of the cheapest in all of accessibility, and where it lives depends on how your site is built.

Block themes. Set it once in theme.json, and every content link inherits it:

{
  "version": 3,
  "styles": {
    "elements": {
      "link": {
        "typography": {
          "textDecoration": "underline"
        }
      }
    }
  }
}

The same control is available without touching files: in the Site Editor, open Styles, and set the link element’s decoration to underline. Recent default themes ship this way already — if yours does not, it is a two-minute change.

Classic themes and child themes. Add the rule to your child theme’s stylesheet, or to Appearance → Customise → Additional CSS:

main a:not(.button):not(.wp-element-button),
article a:not(.button):not(.wp-element-button),
.entry-content a:not(.button):not(.wp-element-button),
.wp-block-post-content a:not(.button):not(.wp-element-button) {
	text-decoration-line: underline;
	text-decoration-thickness: max(1px, 0.08em);
	text-underline-offset: 0.15em;
}

Then find the rule that removed the underline in the first place — search the theme’s stylesheet for text-decoration: none — and note where it applies, because it will keep fighting you on any selector you did not cover.

Page builders. Elementor, Divi and their peers keep a global link style in their site settings. Set the underline there, once, rather than per widget — a per-widget fix is the one that silently misses next month’s new section. While you are in the settings, resist the common pattern of removing the underline on hover; the cue should persist, and hover can add weight instead:

.entry-content a:hover {
	text-decoration-thickness: max(2px, 0.12em);
}

Where it matters most in WooCommerce. The long description and tabs on a product page, where “see the size guide” and “read our washing instructions” live. Delivery, returns and FAQ pages, which are dense with in-sentence links. And the checkout terms line — the terms-and-conditions link sits inside a sentence inside a label, which is the exact colour-only pattern, on the page where a missed link costs the most.

If your brand direction genuinely cannot accept underlines at rest, the conformant alternative is G183 in full: verify a 3:1 ratio between link colour and body colour on every combination, and add an underline on both hover and focus. It can be done. It also has to be re-verified every time a colour token changes, and it gives a touchscreen user nothing — which is why we apply the underline and recommend you keep it.

How you know it worked

1. Turn your screen greyscale — both macOS and Windows have a colour filter in their accessibility settings, and phones do too — and read a product description. Every link should still announce itself. This is the whole criterion in one test: if you can find the links without colour, so can everyone.
2. View the served source. If Klarvo applied the fix, the page carries a Klarvo-delivered stylesheet opening with the verification sentinel --klarvo-fix-profiles:1 and containing text-decoration-line:underline — in the HTML from the server, not conjured after load.
3. Check the exclusions held: your Add to basket buttons and menu items should look exactly as they did. If a button has sprouted an underline, it is missing its .button or .wp-element-button class — worth fixing anyway, because that class is how the rest of the ecosystem recognises it too.
4. Re-scan. The klarvo.content-link-underline count for the page should be zero, and the family’s open count clears only once the served profile has been independently confirmed — not when the change was queued.
5. Keep the judgement calls in view. A colour-coded stock status or a chart legend is still a 1.4.1 question that no underline answers; those findings remain open in the report for a person, which is exactly where they belong.