WCAG 2.4.4 — Link Purpose (In Context) | Jeikin

What this requires

Every link's purpose must be determinable from the link text alone, or from the link text combined with its programmatically-determined context — the surrounding sentence, the paragraph, the list item, or the table cell containing it. Screen-reader users often navigate by pulling up a list of every link on the page; in that view, "Click here", "Read more", and "Learn more" are indistinguishable.

How AI coding tools fail this

When asked for "a card with a Read more link" or "a CTA at the bottom", AI assistants generate the text the marketing brief asked for — literally "Read more" or "Learn more" — without considering that the link will be encountered out of context. The component looks fine in the visual mockup. It's a barrier the moment a screen-reader user opens the link list.

The other common failure: link text that reads naturally in the sentence but says nothing on its own. "You can find the documentation here." Out of context, "here" is a navigation dead-end.

A third pattern: identical link text repeated across multiple targets on the same page. A list of articles where each one is wrapped in a "Read more" link looks consistent visually and is unusable for screen reader navigation — every item announces the same thing.

Failing examples

Generic link text with no context:

<a href="/pricing">Click here</a>

Identical link text pointing to different destinations — the canonical 2.4.4 failure, since the link text is the same and the article title isn't programmatically associated with the link:

<ul>
  <li>
    <h3>Q3 revenue update</h3>
    <a href="/blog/q3-revenue">Read more</a>
  </li>
  <li>
    <h3>Hiring plans for 2027</h3>
    <a href="/blog/hiring-plans">Read more</a>
  </li>
</ul>

Passing examples

Link text that stands alone:

<a href="/pricing">View our pricing plans</a>

Descriptive link inside the sentence:

<p>
  Read the <a href="/docs">full Jeikin documentation</a>
  for setup instructions.
</p>

When the visible text genuinely cannot change, an aria-label overrides what assistive tech announces:

<a href="/article-42" aria-label="Read Jeikin on the GitHub Marketplace">
  Read more
</a>

Edge cases

Identical destinations can share identical link text. WCAG only fails when the same text points to different destinations.
Image-only links must have alt text on the image describing the destination, not the image content. <a href="/home"><img alt="Home"></a>, not <img alt="Logo">.
Icon-only links need an aria-label (or visually hidden text) giving the destination.
Contextual override. WCAG 2.4.4 allows the surrounding paragraph, list item, or table cell as context. Section 2.4.9 ("Link Purpose Link Only") is the stricter AAA version that requires the link text alone to be self-sufficient.
Multiple links with the same text but different aria-label values still announce as the aria-label, which lets you keep "Read more" visually consistent while exposing distinct labels to assistive tech.

How Jeikin handles this

Jeikin's CLI scanner detects generic link text ("click here", "read more", "learn more", "here", "more") and flags it against WCAG 2.4.4. When the same project has multiple instances of identical link text pointing to different URLs, the scanner aggregates them into a single finding with all locations listed.

The MCP server returns suggested rewrites grounded in the surrounding content of the page, so the AI assistant can propose a fix that reads naturally rather than a rote "describe the destination" template.