Link is not distinguishable from surrounding text without color

What is this issue?

An <a> element is nested inside a block of running text (a paragraph, list item, or similar text container), and its only visual difference from the surrounding non-link text is its color. There’s no underline, no bold weight, no icon, and no other cue that survives if color is removed or perceived differently.

The link functions correctly and the color contrast between the link text and its background may even pass a standard contrast check. The specific defect this rule targets is narrower: the link is distinguishable from the surrounding text only through color, which is exactly the signal some users can’t reliably perceive.

Why does this matter?

Roughly 1 in 12 men and 1 in 200 women have some form of color vision deficiency, and many more users view pages in grayscale, high-contrast mode, or under lighting conditions that wash out subtle color differences. For every one of them, a color-only link inside a paragraph reads as plain, uninteractive text: there’s nothing marking it as clickable until they happen to hover or tab onto it by chance.

This isn’t a hypothetical edge case: it fails silently. Unlike a broken link, which produces an error the moment someone clicks it, a color-only link produces no error at all: the user simply never discovers there was something to click, and the information or action behind that link is effectively invisible to them.

Who is affected?

• Low vision: reduced but not absent vision, sometimes relying on screen magnification or high contrast display modes, can make subtle color differences between link text and body text difficult or impossible to distinguish, even when both colors are individually visible.
• Cognitive disabilities: users who scan text quickly rather than reading every word rely on strong, unambiguous visual cues to spot interactive elements; a color-only distinction that requires careful attention to notice adds friction that a bold underline avoids entirely.

What users experience

Elena has red-green color blindness and reads a company blog post about accessibility best practices on her laptop. The article’s body text links to a related guide, styled only in a shade of blue that reads as barely different from the surrounding gray-black paragraph text under her color perception. She finishes the article without ever noticing the guide was linked, missing content the author specifically wanted her to find, because nothing about the text’s shape or weight told her it was clickable.

How do I fix it?

Add a non-color visual cue to links that appear inside blocks of text: an underline is the simplest and most universally recognized choice. This works because an underline is a shape-based signal, not a color-based one, so it survives grayscale rendering, color vision deficiencies, and high-contrast display modes equally well, while still matching the convention most users already associate with “this is a link.”

Bold weight or a distinct icon can serve the same purpose if underline doesn’t fit a design’s visual language, as long as the cue is visible in the link’s default resting state, not only on hover or focus. Links outside of body text (navigation items, buttons, and card titles) are generally exempt from this specific rule, since their position and surrounding layout already mark them as interactive without needing an underline.

Code Examples

a { color: #2563eb; text-decoration: none; }

/* Method 1: underline all links (simplest, safest default) */
a { color: #2563eb; text-decoration: underline; }

/* Method 2: underline only links inside body text, if nav/buttons
   are already visually distinct without one */
nav a, .button-link { text-decoration: none; }
article a, p a { color: #2563eb; text-decoration: underline; }

Method 1 restores the underline globally, which is the safest default because it guarantees every link everywhere carries a non-color cue with no risk of missing a text-block link somewhere on the site. Method 2 shows the more common real-world pattern, where navigation and button-styled links stay underline-free because their layout already marks them as interactive, while links specifically inside article and p elements keep the underline this rule requires.

Common Mistakes

Mistake: “The link color has a high contrast ratio against the background, so it’s accessible.” A high contrast ratio between the link color and the page background is a separate requirement from this rule, and passing one says nothing about the other. This rule is about whether the link is distinguishable from the surrounding text, which is a color-vision problem a contrast ratio alone doesn’t solve: someone can perceive that blue text is darker or lighter than the page background without being able to tell that it’s a different color from the black paragraph text around it.

Mistake: “Adding an underline on :hover is enough, since users will discover the link eventually.” A hover-only underline is invisible to anyone browsing by touch, since touchscreens have no hover state, and it’s invisible to a mouse user until their cursor happens to land exactly on that word. The cue needs to be present in the link’s default, resting state; hover and focus styles can reinforce it but can’t be the only place it appears.

Mistake: “This rule means every link on the site needs an underline.” Links outside running text (navigation menus, buttons, card headers) are generally exempt, since their position, spacing, and surrounding layout already signal that they’re interactive without relying on color. Applying underlines everywhere indiscriminately is a valid, safe choice, but it isn’t what the rule requires; it specifically targets links embedded inline within blocks of text.

How RedFlag Detects This

Automated: axe-core rule, runs on every scan. RedFlag calls axe-core’s link-in-text-block rule as part of every scan, restricted to the WCAG 2.0/2.1/2.2 A and AA rule set. The check identifies links whose parent element contains a meaningful amount of surrounding non-link text, then compares the link’s computed styles (text-decoration, font-weight, and similar) against the surrounding text’s styles to determine whether color is the only distinguishing factor.

False negative: axe-core evaluates computed CSS properties, not final rendered pixels: a design that visually differentiates a link through a subtle background shading or an icon axe-core doesn’t check for could pass the automated rule while still being hard for some users to spot in practice. False positive: a link styled with an underline that’s rendered nearly invisible due to a very thin text-decoration-thickness or a color close to the background can pass this automated check while still being difficult to perceive, since axe-core confirms the property is present, not that it’s visually adequate. Manual step: view the page in grayscale (most browser DevTools offer a vision-deficiency emulation mode) and confirm every in-text link remains clearly identifiable without any color information at all.

Manual Testing

1. Open the page in Chrome DevTools and use the Rendering panel’s “Emulate vision deficiencies” option, set to grayscale or a color vision deficiency profile.
2. Scan every paragraph and block of body text on the page.
3. Confirm every link is still clearly identifiable as a link (by underline, weight, or another shape-based cue) with no color information available.
4. Flag any link that blends into the surrounding text once color is removed.
5. Separately confirm links outside of text blocks (navigation, buttons, cards) remain understandable through their layout even without an underline, since they’re evaluated differently by this rule.

Related WCAG Success Criteria

1.4.1 Use of Color: Color must not be the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. A color-only link inside a paragraph is a direct, textbook example of this failure: the link’s “clickability” is information conveyed through color alone.

Related Issues

Text contrast is too low to read is a separate, complementary requirement worth checking on any link this rule flags: a link needs both enough contrast against its background and a non-color cue distinguishing it from surrounding text.

Text contrast is too low for AAA covers the stricter AAA-level version of the same contrast concern, relevant if a site targets the higher conformance bar.

Button or link has no accessible name is worth checking alongside this rule, since a link can be visually distinguishable and still fail to announce a usable name to assistive technology.

Link text is generic and gives no context covers a different link-quality problem in the same neighborhood: text that’s visually clear as a link but doesn’t describe where it goes.

Link opens in a new tab without warning text is another context-communication gap for links, focused on behavior rather than visual identification.

References

• W3C Understanding 1.4.1: Use of Color
• W3C Technique G183: Using a contrast ratio of 3:1 with surrounding text and providing additional visual cues
• MDN: text-decoration