Links Must Be Distinguished from Surrounding Text: How to Fix It

What this check flags

This check fires when an in-text link is set apart from the words around it by color alone, with nothing else — no underline, no bold, no icon — to signal that it is clickable. That trips WCAG 2.1 Success Criterion 1.4.1 (Use of Color): anyone who cannot reliably tell your link color from your body-text color simply cannot find the link, and a chunk of your internal linking quietly stops working for them.

The people who lose out are not edge cases. Roughly one in twelve men has some form of color vision deficiency. Add low-vision users, aging eyes, a phone screen in direct sun, and a grayscale e-ink reader, and "the link is a slightly different shade of gray" becomes "there is no visible link at all." Color is allowed to be part of the signal. It just cannot be the only part.

A real failing example, and the fix

Here is the pattern that sets this off. A stylesheet strips the default underline off in-content links and leans on a link color that sits close to the paragraph color:

<style>
  article p { color: #444; }
  article p a {
    color: #6a7fa5;          /* muted blue, no other cue */
    text-decoration: none;   /* underline removed */
  }
</style>

<p>We break down the numbers in our
   <a href="/reports/q3">quarterly summary</a>.</p>

Desaturate that page and "quarterly summary" vanishes into the sentence. The fix is to put back a non-color cue. An underline is the one every user already reads as "link," so it is the safest default for body copy:

<style>
  article p a {
    color: #1a5fb4;
    text-decoration: underline;      /* the non-color signal */
    text-underline-offset: 0.15em;   /* a little breathing room */
  }
  article p a:hover,
  article p a:focus {
    text-decoration-thickness: 2px;  /* reinforce on interaction */
  }
</style>

If an underline genuinely clashes with your design in one specific context (a nav bar, a card grid), you can swap it for another distinguishing cue — bold weight, a persistent icon, or a bottom border with at least a 3:1 contrast ratio against the surrounding text. What you cannot do is remove every cue and keep only hue.

Which cues actually satisfy 1.4.1

Not every "difference" counts. The distinguishing signal has to be perceivable without relying on color perception. This table sorts the common approaches:

One nuance worth knowing: WCAG carves out an exception when link text and surrounding text differ in luminance by a 3:1 ratio and get an extra cue on hover and focus. In practice, hitting that luminance gap reliably across a whole site is fiddly, so a visible underline is far less error-prone than chasing the exception.

How to detect it

1. Run your page through an automated checker (axe, Lighthouse, WAVE). They flag "Links must be distinguishable without relying on color" or the equivalent 1.4.1 rule.
2. Grayscale the page. In Chrome DevTools open the Rendering panel and set "Emulate vision deficiencies" to Achromatopsia, or apply filter: grayscale(1). Scan a paragraph: can you still spot every link?
3. Inspect your in-content link CSS for text-decoration: none without a replacement cue — that combination is the usual culprit.
4. Check hover-only underlines. If a link only underlines on :hover or :focus, it fails for anyone not currently interacting with it.
5. Test on a phone in bright light. Real-world glare exposes low-contrast links that look fine on a calibrated desktop monitor.

How to fix it

1. Give body-content links a cue that shows at rest — underline is the default choice.
2. Keep the underline present in the resting state; add extra emphasis (thicker underline, bold) on hover and focus rather than introducing the cue there.
3. Where an underline is genuinely undesirable, substitute bold weight, a persistent icon, or a 3:1 bottom border — never bare color.
4. Scope the rule so it targets prose. Navigation, buttons, and card links that are already visually obvious as controls do not need the same treatment.
5. Re-run the grayscale test after the change to confirm every link is still findable.

FAQ

Does every link on the page need an underline?

No. The criterion targets links embedded in blocks of text, where a reader has to distinguish the link from the words around it. Navigation menus, buttons, and obvious call-to-action tiles read as interactive on their own, so they are not the concern here. It is the link sitting inside a sentence that must stand out by more than color.

Can I use underline-on-hover instead of a permanent underline?

Not as your only cue. If the link is indistinguishable until someone hovers, then keyboard users, touch users, and anyone scanning the page cannot find it in the first place. Show a resting cue, and treat hover/focus styling as reinforcement.

Is a color difference ever enough on its own?

Only under a narrow WCAG exception: the link text must differ from surrounding text by at least a 3:1 contrast ratio and gain an additional cue on hover and focus. Meeting that consistently is harder than it sounds, which is why a visible underline is the pragmatic answer for body copy.

Does this affect SEO or just accessibility?

Primarily accessibility, but there is a real usability knock-on. Links a user cannot see are links they cannot click, which flattens engagement with your internal linking and buries the pages you are trying to surface. Making links obvious keeps that link equity actually reachable.

How is this different from links needing discernible text?

Different failure. This check is about visually telling a link apart from nearby text using more than color. A separate rule — that links must have discernible text — is about whether the link has any readable label at all for assistive tech. A link can pass one and fail the other.

For the bigger picture on where these rules and search overlap, see Accessibility and SEO, and if you are auditing your link graph, the internal linking guide covers making those links count once they are visible.