WCAG 2.4.4 Link Purpose (In Context) requires that the purpose of every link be understandable either from the link text alone or from the link text combined with its surrounding context that assistive technology can reach — the same sentence, paragraph, list item, or table cell. It is a Level A criterion, the minimum bar for conformance.

What WCAG 2.4.4 actually requires

The W3C wording is precise: the purpose of each link can be determined “from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.”

Two things make this criterion distinct. First, context counts — unlike its stricter sibling 2.4.9 Link Purpose (Link Only), 2.4.4 lets you rely on text around the link. But the context has to be programmatically determined, meaning a screen reader can actually find it. W3C limits that to a short list:

  • the same sentence as the link,
  • the same paragraph,
  • the same list item (or the parent list item in nested lists),
  • the same table cell, or its associated header cells,
  • and an accessible name supplied by aria-label or aria-labelledby.

Context that sits in an unrelated part of the page — a caption three sections away, a heading the link isn’t grouped under — does not count. That mistake is its own documented failure, F63.

Second, there’s one narrow exception: links that are deliberately ambiguous to everyone. W3C’s example is a guessing game with “door #1, door #2, door #3” where the mystery is the point. If sighted users also can’t tell where it goes, you haven’t disadvantaged anyone.

Who it affects

The criterion exists because of how non-visual navigation works. Assistive technology can pull up a list of every link on the page, stripped of its visual surroundings, so users can jump straight to the one they want:

  • Blind screen reader users (JAWS, NVDA, VoiceOver) open a links list or rotor. A page of fifteen “Read more” links becomes fifteen identical, meaningless entries.
  • People with low vision using screen magnifiers see only a small slice of the page, so a link’s far-away context may be off-screen.
  • People with motor impairments tab through links to skip the ones they don’t want; vague text forces them to visit each one to find out.
  • People with cognitive disabilities get disoriented when link text doesn’t predict the destination.

The W3C Understanding document names all four groups. This is a navigation problem, not just a labeling nicety.

Concrete failures and how to fix them

1. Bare “click here” / “read more” links. This is the classic case. The link text means nothing in a links list. W3C failure technique F84 describes exactly this — non-specific text like “click here” or “more” with no mechanism to clarify it.

<!-- Fails: "here" tells a links-list user nothing -->
<p>To read our refund policy, click <a href="/refunds">here</a>.</p>

<!-- Passes: the link text states the destination -->
<p>Read our <a href="/refunds">refund policy</a>.</p>

2. Repeated “Read more” on a card grid. A blog or product grid where every card ends in the same “Read more” link. Each one may pass 2.4.4 if its own heading is in the same context — but the robust fix is a visually hidden suffix so the accessible name is unique:

<a href="/blog/aria-basics">
  Read more
  <span class="visually-hidden"> about ARIA basics</span>
</a>

The visually-hidden class keeps the design clean while a screen reader announces “Read more about ARIA basics.” That’s W3C technique C7 (hiding extra link text with CSS).

3. Icon-only or image-only links with no accessible name. A cart icon, a social-media glyph, or an image that is the link but carries alt="" or no alt. W3C failure F89 records this as a 2.4.4 failure (it also breaks 4.1.2 Name, Role, Value).

<!-- Fails: no accessible name, announced as "link" or a filename -->
<a href="/cart"><img src="cart.svg" alt=""></a>

<!-- Passes: alt text names the destination -->
<a href="/cart"><img src="cart.svg" alt="View shopping cart"></a>

<!-- Passes for inline SVG/icon fonts: aria-label on the link -->
<a href="/cart" aria-label="View shopping cart"><svg aria-hidden="true">…</svg></a>

4. Identical text pointing to different places. Two “Download” links — one for a PDF, one for a Word doc. Same text, different destinations confuses users. W3C’s best practice: same destination should share link text; different destinations should differ. Make them “Download the PDF” and “Download the Word version.”

5. Raw URLs as link text. A long https://example.com/path?ref=... read character-by-character by a screen reader is hostile. Replace it with the page or document name.

How to test WCAG 2.4.4

You can verify this faster than almost any other criterion because the right tool is the failure case — the links list:

  1. Open the links list. In NVDA press Insert + F7 (Elements List → Links). In JAWS, the same shortcut. In VoiceOver, open the Rotor (Ctrl + Option + U) and arrow to Links.
  2. Read each entry out of context. If you can’t tell where “here,” “more,” “details,” or “download” leads, that link is a candidate failure.
  3. Check icon and image links for an accessible name — hover for a tooltip is not enough; inspect the alt, aria-label, or aria-labelledby.
  4. Spot duplicate text going to different destinations.
  5. Run an automated pass to flag the obvious ones at scale, then judge context by hand — a scanner can’t always tell whether “Read more” is rescued by nearby text. That judgment is why thorough work pairs tools with manual review. See also how screen readers work for what your testers actually hear.

Vague link text is uniquely cheap to allege because the evidence is the links list itself: a plaintiff’s tester opens NVDA, presses Insert + F7, and screenshots a column of identical “click here” or “read more” entries. There is no rendering, no replay, no expert needed — the screenshot is the finding, which is why ambiguous links recur in ADA demand letters. And the volume of those filings is documented, not hypothetical: UsableNet’s year-end tracker counted 4,187 federal and state digital accessibility lawsuits in 2024, with filings running above 4,000 a year since 2021 (UsableNet lawsuit tracker).

Two specifics make 2.4.4 hard to dismiss. First, it is a Level A criterion — the baseline. Under ADA Title III, courts and the Department of Justice treat WCAG 2.1 AA as the practical benchmark, and 2.4.4 sits below even that AA line, so no tier of conformance lets you skip it. Second, the federal government’s own guidance already requires the fix: the GSA’s Section508.gov tells teams to write link text that “makes sense when read in isolation” and to drop “click here” and “read more” outright. (For the official success criterion itself, the authoritative source is the W3C Web Accessibility Initiative.)

Treat this as general background, not legal advice — your actual exposure depends on your site and jurisdiction, so confirm it with a qualified attorney.

Fixing it the right way

Link purpose is the rare criterion an automated widget structurally cannot fix, because the fix depends on meaning the widget doesn’t have. An accessibility overlay can detect that a link reads “Read more,” but it cannot know this “Read more” leads to the ARIA basics guide and that one to the refund policy — so it leaves both ambiguous or, worse, injects a wrong guess. That’s not a hypothetical risk: UsableNet found that more than 1,000 businesses running an overlay were sued anyway in 2024.

The real remediation is editorial and lives in your markup. For repeated “Read more” links on a card grid we append a visually hidden suffix with technique C7 — Read more<span class="visually-hidden"> about ARIA basics</span> — so the design stays clean while the screen reader announces a unique name. For icon and image links we add the destination as alt text or an aria-label on the anchor (aria-label="View shopping cart"), and we split duplicate “Download” links into “Download the PDF” and “Download the Word version.” Because that’s hand work, Curbcut is deliberately anti-overlay: a free scan lists every vague, empty, and icon-only link on your site, and then we rewrite them in your code so the default experience passes for real screen-reader users.