WCAG 2.4.4 Link Purpose (In Context): fixing "click here"

In the 2026 WebAIM Million, 46.3% of home pages had a link with no name at all and 15.2% had vague link text such as "click here" or "more". This page covers exactly what counts as context for a link, why a heading above a "Read more" does not, how images, aria-label and visible labels interact, working fixes for repeated "read more" links, real failing and passing code, a step-by-step test, and what GotAlt's tools check and cannot check.

What WCAG 2.4.4 requires

Success criterion 2.4.4 asks that 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 would be ambiguous to users in general (W3C, WCAG 2.2). It is Level A, has been in WCAG since WCAG 2.0, and is kept in 2.1 and 2.2. Its AAA sibling, 2.4.9 Link Purpose (Link Only), drops the context allowance: the purpose must be identifiable "from link text alone".

W3C's stated intent is to help people "decide whether they want to follow the link." The Understanding document adds the reason that matters in practice: assistive technology can list every link on a page, so link text that is as meaningful as possible "will aid users who want to choose from this list of links" (Understanding 2.4.4). WebAIM makes the same point: screen reader users often move from link to link or open a list of all links, so "links should make sense out of context".

Because 2.4.4 is Level A, it is inside every target the laws in our register name: WCAG 2.0 AA for Section 508 and Ontario's AODA, and WCAG 2.1 AA for the ADA Title II web rule and, through EN 301 549, the European Accessibility Act. Our laws hub covers each. This page explains a technical standard and is not legal advice.

How often links fail

The 2026 WebAIM Million (data collected February 2026) is the standard reference for real-world failure rates. Its link findings:

WebAIM notes that linked images with missing alt text result "in links that were not descriptive". Automated tests find what they can match, so these figures are a floor, not a total. Our pages on the most common accessibility errors and WCAG 1.1.1 cover the rest of that list.

What counts as context, and what does not

The phrase "programmatically determined link context" is defined by W3C as "additional information that can be programmatically determined from relationships with a link". For HTML, W3C's example is text "in the same paragraph, list item, or table cell as the link" or in a table header cell associated with the link's cell, and it notes that because screen readers interpret punctuation they can also give the context of the current sentence. Everything else is visual context, which does not count. W3C also says context works best when it comes first: "most usable if it precedes the link".

The failure W3C documents as F63 is easy to produce. A news site puts a summary paragraph in one <p> and the link "Read More..." in the next. Sighted visitors read them as one block, but the link is not in the same paragraph as its explanation, so the context is not programmatic.

The "ambiguous to users in general" exception

W3C defines ambiguous to users in general as a purpose that "cannot be determined from the link and all information of the web page", presented together with the link, so that "readers without disabilities would not know what a link would do" until they activate it. Its example is a single word, "guava", linked inside the sentence "One of the notable exports is guava": the link could lead to a definition, an export chart or a photograph, and nobody knows which. Its second example is a game with links called "door #1", "door #2" and "door #3", where the mystery is the point.

The exception is narrower than it sounds, and the narrowness is what catches teams out:

• A "Read more" under a visible headline is not ambiguous in general. A sighted visitor can see the headline, so the purpose can be worked out from the page as presented. The exception does not apply, and the context has to be available to software too.
• The exception does not excuse missing context. Whatever context the page offers "must be made available in the link text or programmatically associated with the link", W3C says.
• Mystery on purpose is allowed when the surprise is the point for every user, as in the game.

Image links and icon links

A link whose only content is an image takes its name from the image's alt text. With no alt, or with alt="" and no other name, the link is announced without a purpose. W3C documents this as failure F89, an image link with no name, which fails 2.4.4, 2.4.9 and 4.1.2 together. The data above shows how common it is: one in four linked images on home pages had no alt text.

Three patterns cover most cases:

• Image only: the alt text states where the link goes ("View cart"), not what the picture looks like ("Cart icon").
• Icon beside text, in one link: give the icon alt="". W3C's own example does exactly this, because "the purpose of the link is already described by the text of the link".
• Image link and text link to the same place, as two separate links: combine them into one link (technique H2, combining adjacent image and text links). Keyboard users then meet one link and a links list shows no duplicate. In F89's own example, a screen reader falls back to guessing at a name from the image file, announcing something like "football dot gif".

Inline SVG and icon fonts work the same way: the link needs a name from visible text or an aria-label, and hiding the decorative icon itself with aria-hidden="true" keeps it from adding noise. Alt text for images in general is the subject of our alt text examples page.

aria-label, and why the visible text has to be in it

The aria-label attribute can give a vague link a precise name, and W3C lists it as a sufficient technique (ARIA8). But the technique page states a consequence people overlook: "the aria-label text will override the text supplied within the link", and in some assistive technologies the label "will show in the list of links instead of the actual link text". The attribute replaces the visible text as the link's name. That connects to a second Level A criterion.

2.5.3 Label in Name (new in WCAG 2.1) requires that for components with visible text labels, "the name contains the text that is presented visually". Its Note adds a best practice: put the visible text at the start of the name. The reason is speech input. People who operate a page by voice say what they see, such as "click Read more", and a name that does not contain those words does not respond. So the safe pattern is the visible words, then the detail. The ARIA8 example does exactly this:

<a href="/taxhike"
   aria-label="Read more about
   Seminole tax hike">Read more</a>

The pattern that fails 2.5.3 swaps the visible words for different ones, so the label a voice user can see is not in the name (W3C documents the pattern as failure F96, an accessible name that does not match the visible label; this sample adapts the ARIA8 example):

<a href="/taxhike"
   aria-label="Seminole tax hike">
  Read more</a>

F96 has a second example that catches hidden-text fixes. A link reads "Download specification" on screen, but hidden text makes its name "Download gizmo specification". The visible words are all in the name, yet "there is no string match", so a voice command may not activate the link. Keep the visible words together, in order, and add the extra words before or after them, never between them.

Where the explanation is already visible on the page, such as a headline, W3C's ARIA8 page says to use aria-labelledby instead of aria-label, which is the next section.

Repeated "read more" links

The news-list pattern, with a "Read more" after every summary, is the most common source of vague links, and W3C's own examples show both the leniency and the cost. In its news-summary example the paragraph supplies the context, so the criterion is met. But a links list then shows "Read more" ten times. Four fixes work, in rough order of preference:

1. Name the destination in the link text. Make the headline the link, or write "Read the Seminole tax hike story". Nothing else needs to be maintained.
2. Reference the headline with aria-labelledby so the name becomes the visible words plus the headline. W3C's example (ARIA7) produces the name "Read more ...Storms hit east coast" and shows the same text in the links list. Referencing the link's own id keeps the visible words first:

<h2 id="headline">Storms hit east coast</h2>
<p>Torrential rain has struck the coast.
  <a id="r1" href="/storms"
     aria-labelledby="r1 headline">Read more</a>
</p>

3. Add visually hidden text after the visible words (technique C7, hiding part of the link text with CSS). The hidden part must be clipped off screen, not hidden with display: none or visibility: hidden, which remove it from assistive technology as well. W3C itself cautions that some screen reader users find this technique "overly chatty", and that it works best when the hidden text is not repetitive.

<a href="/storms">Read more<span
  class="visually-hidden"> about the
  storms on the east coast</span></a>

4. Use aria-label that starts with the visible words, as in the previous section. Fine for a few links, harder to maintain across a template.

Whichever you choose, apply two rules from W3C and WebAIM. Links with different destinations should have different link text, and links to the same destination should use the same text. W3C calls both best practices; the second is also a requirement under 3.2.4 Consistent Identification for pages in a set (Understanding 2.4.4). And put the distinguishing words first: WebAIM advises "Products (opens in a new window)" over "Link opens in a new window: Products", because the repeated prefix makes a links list harder to scan.

Rewriting vague links

More failing and passing code

A vague link in a list

Failing. A links list shows "Download" twice, and nothing in the list item says which file:

<li><a href="/r-2026.pdf">Download</a></li>
<li><a href="/r-2025.pdf">Download</a></li>

Passing:

<li><a href="/r-2026.pdf">2026 annual
  report (PDF)</a></li>
<li><a href="/r-2025.pdf">2025 annual
  report (PDF)</a></li>

A link whose context is in another paragraph (F63)

Failing:

<p>Torrential rain has struck the coast.</p>
<p><a href="/storms">Read more</a></p>

Passing at Level A, by putting the link in the paragraph it belongs to (technique H78). It would still read "Read more" in a links list, so the earlier fixes are better:

<p>Torrential rain has struck the coast.
  <a href="/storms">Read more</a></p>

A sentence that carries the context

Passing at Level A, and W3C's own example for G53, because the information that explains the link comes first in the same sentence. It fails the AAA criterion 2.4.9, which asks for the purpose from the link alone:

<p>To advertise on this page,
  <a href="/advertise">click here</a>.</p>

Better, and passing both:

<p><a href="/advertise">Advertise on
  this page</a>.</p>

An image link with no name (F89)

Failing:

<a href="/cart"><img src="cart.svg" alt=""></a>

Passing, with alt text that says where the link goes:

<a href="/cart"><img src="cart.svg"
  alt="View cart"></a>

An icon-only link

Failing. There is no text, no aria-label and the SVG has no name:

<a href="/search">
  <svg class="icon">...</svg>
</a>

Passing. The link carries the name and the icon is hidden from assistive technology:

<a href="/search" aria-label="Search">
  <svg class="icon" aria-hidden="true">...</svg>
</a>

Image and text as two links to one page

Failing, in the sense of W3C's F89 example: the image link has an empty name and sits beside a text link to the same page, so users meet two links where one would do:

<a href="/scores"><img src="ball.gif" alt=""></a>
<a href="/scores">Football scoreboard</a>

Passing. One link, with the icon given empty alt text (technique H2):

<a href="/scores">
  <img src="ball.gif" alt="">
  Football scoreboard
</a>

How to test WCAG 2.4.4, step by step

1. List every link and its name. With a screen reader this is a links list: in NVDA, WebAIM's guide says NVDA+F7 opens the Elements List with the page's links, headings and landmarks, and the K key moves from link to link. For a quick static check, run the link text checker on a page address; for the rendered page, the accessibility bookmarklet. Or print them yourself in the browser console:

for (const a of document.links) {
  console.log(a.textContent.trim(),
    a.getAttribute("aria-label"),
    a.href);
}

2. Mark the names that do not identify a destination alone: generic phrases, bare URLs, single words like "more", the same name used for different destinations, and icon-only links.
3. Look for programmatic context for each mark. Is the explanation in the same sentence, paragraph, list item or table cell, or supplied with aria-labelledby, aria-label or aria-describedby? If yes, note which technique makes it pass. If the only explanation is a heading, an earlier paragraph, a card layout or a neighboring table row, it fails (F63).
4. Apply the "ambiguous to users in general" exception last. Use it only if a sighted visitor looking at the whole page could not tell either.
5. Read the real accessible name. In Chrome's developer tools, the Accessibility tab shows an element's computed accessibility properties, and Firefox has an Accessibility Inspector. An aria-label or aria-labelledby may have replaced the text you can see.
6. Compare the name with the visible text (2.5.3). The name should contain the words on screen, ideally first.
7. Check image and icon links for a name. A link whose only content is an image with alt="" and no other name is the F89 failure.
8. Check consistency. Same destination, same text; different destinations, different text.
9. Run it again after the page changes state. Menus, tabs, "load more" buttons and scripts add links that a one-time static check never saw.

Our guide to testing website accessibility fits this into a full manual pass.

Common false positives and false negatives

What GotAlt's tools check, and what they cannot

Related criteria and further reading

• 2.4.9 Link Purpose (Link Only) (AAA): the purpose from the link text alone, with no context allowance.
• 2.5.3 Label in Name (A): the accessible name must contain the visible label.
• 4.1.2 Name, Role, Value (A): every link needs a name that software can read.
• 1.1.1 Non-text Content (A): alt text, including the alt of a linked image.
• 3.2.4 Consistent Identification (AA): links with the same function use the same text across a set of pages.
• 2.4.6 Headings and Labels (AA): headings and labels describe their topic or purpose.

For every criterion in one place, see WCAG 2.2 criteria explained and the WCAG 2.2 checklist. Theme and template notes are in our guides for Shopify, WordPress, Wix, Squarespace and Webflow.