WCAG 2.4.4: Link Purpose (In Context)
A link should tell you where it goes before you follow it. Under 2.4.4, the purpose of every link must be clear from its text alone, or from the text together with its programmatically-determined context. A page full of "click here" and "read more" links — meaningless when a screen reader reads them as a list — is the classic failure of this Level A criterion.
The success criterion, in full
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.
Why link purpose matters
Screen reader users rarely read a page top to bottom. One of the fastest ways to navigate is to open a list of every link on the page — in NVDA and JAWS you press a single key to do this — and skim it to find the one you want. In that list, each link is read by its accessible name with no surrounding text. Ten links that all say "Read more" collapse into ten indistinguishable rows, and the user has no way to choose between them without visiting each one.
The benefit is far wider than screen readers. Descriptive links help people with cognitive disabilities understand what will happen, help speech-input users who say the link's name to activate it, help sighted users scanning a page, and improve SEO because search engines weight link text as a signal of the destination's topic. Writing a clear link is one of the highest-leverage accessibility habits a content team can build.
What 2.4.4 actually requires
There are three testable ideas behind the criterion. Get these right and your links communicate their destination to everyone.
1. The link text alone can name the destination
Read with no surrounding words, the link still tells you where it goes.
The simplest way to pass 2.4.4 is to make the visible link text describe its own purpose: "Download the 2026 accessibility report (PDF)" instead of "Download". Screen reader users frequently pull up a list of every link on a page and tab through them out of context, so text that reads clearly on its own is the most robust solution and helps every user scan faster.
2. ...or the purpose is clear from programmatically-determined context
The sentence, list item, paragraph, table cell, or heading the link sits in supplies the meaning.
2.4.4 also passes when the purpose can be determined from the link text combined with its programmatically-determined context — the enclosing sentence, paragraph, list item, table cell with its header, or the heading the link follows. The key word is programmatically-determined: the relationship must be exposable to assistive technology, not just visually implied by nearby layout. "Read more" at the end of a paragraph about the EAA can pass if that paragraph is genuinely the link's context.
3. Identical link text should go to the same place
Don't make two links read the same but point to different destinations.
Where two or more links have the same accessible name, users reasonably expect them to do the same thing. If "Learn more" appears five times pointing to five different pages, a screen reader user scanning the links list cannot tell them apart. Either make each name unique, or give them distinguishing context that assistive technology can reach.
The rule of thumb: if you read the link text with your eyes closed to everything around it and still know where it goes, it passes — and it also satisfies the stricter Level AAA 2.4.9 Link Purpose (Link Only) for free. Self-describing visible text is always the strongest solution.
What counts as "programmatically-determined context"
The criterion lets a link borrow meaning from its surroundings — but only context that assistive technology can actually reach by code, not context a sighted user infers from visual layout. These are the contexts WCAG accepts:
The enclosing sentence
Text in the same sentence as the link. "For pricing, see our plans." — the word 'plans' borrows the sentence as context.
The enclosing paragraph
The paragraph the link sits in. A 'Read more' link at the very end of a paragraph can take that paragraph as its context.
The enclosing list item
The <li> a link belongs to, including text before it in the same item.
The enclosing table cell + headers
A link in a data cell can be understood together with its row and column headers, which screen readers announce.
What does NOT count: a heading two paragraphs up, a nearby image, or text in an adjacent column that is only visually associated. Those relationships are not programmatically-determined, so a screen reader navigating by the links list cannot use them. An explicit association (for example via aria-describedby) does count — but "it's under the right heading visually" alone does not.
Icon links, image links, and ambiguous links
- Image links: the link's accessible name comes from the image's alt text. Describe the destination, not the picture — a logo that links home should be alt="Home" (or the site name), never alt="logo" or empty.
- Icon-only links: a link containing only an SVG or icon-font glyph has no text. Add an aria-label to the link (or a visually-hidden text span) and mark the glyph aria-hidden="true" so it is not announced twice.
- Repeated 'Edit' / 'Delete' links: in a table or card list, ten 'Edit' links are ambiguous on their own. Extend each name with the item it edits — "Edit invoice #1043" — using a visually-hidden span, or rely on the row's header cell as context.
- Links that open new windows or files: tell users in the name. "Annual report (PDF, 2 MB)" or "Opens in a new tab" prevents disorientation and supports related guidance like technique G201.
Whenever you give a link its name through ARIA, keep the visible words inside that name so you do not break speech-input expectations — see 4.1.2 Name, Role, Value for how accessible names are computed.
The exception
2.4.4 has a single, narrow carve-out. Understanding it keeps you from over-flagging genuinely conformant designs.
- When the purpose of a link cannot be determined from the link together with all of its programmatically-determined context, and the link would be ambiguous to users in general — not only to people with disabilities. In that narrow case the criterion does not require it to be resolved, because sighted users are equally in the dark. This is rare in practice; treat it as an edge case, not a loophole.
Code examples
Fixing a "read more" link with a visually-hidden span
Keep the short visible label for design, but extend the accessible name with text only assistive technology reads. This is the most robust fix because the full name works even in a links list.
<!-- BAD: meaningless in a links list -->
<a href="/guides/eaa">Read more</a>
<!-- GOOD: visible "Read more", full name for AT -->
<a href="/guides/eaa">
Read more<span class="sr-only"> about the European Accessibility Act</span>
</a>/* The standard visually-hidden / "sr-only" utility:
removed from view but kept in the accessibility tree. */
.sr-only {
position: absolute;
width: 1px; height: 1px;
padding: 0; margin: -1px;
overflow: hidden;
clip: rect(0 0 0 0);
white-space: nowrap;
border: 0;
}An icon-only link
The link needs an accessible name; the decorative glyph is hidden so it is not announced as part of the name.
<a href="/settings" aria-label="Settings">
<svg aria-hidden="true" focusable="false" width="20" height="20">
<use href="#icon-cog" />
</svg>
</a>Disambiguating repeated action links in a table
Each "Edit" link gets a unique accessible name by naming the row it acts on, so the links list stays meaningful.
<td>
<a href="/invoices/1043/edit">
Edit<span class="sr-only"> invoice #1043</span>
</a>
</td>Common mistakes
- Generic link text — "click here", "read more", "learn more", "here", "this", "more" — repeated across the page with no distinguishing context.
- Using the raw URL as link text ("https://example.com/2026/q1/report-final-v3.pdf"), which screen readers read out character by character.
- Image links with alt text describing the image ("logo", "banner") instead of the destination, or with empty alt that leaves the link with no name at all.
- Icon-only links (search, menu, edit, delete, social icons) with no aria-label or visually-hidden text — a 2.4.4 and 4.1.2 failure.
- Two identical link names pointing to different destinations, so users cannot tell them apart in a links list.
- Relying on visual proximity — "the link is obviously about the heading above it" — when that relationship is not programmatically-determined.
- Overwriting good visible text with an aria-label that omits the visible words, which can break 2.5.3 Label in Name for speech-input users.
- Title attributes used as the only source of link purpose; title text is unreliable across browsers and not exposed to all assistive technology.
How to test for 2.4.4
- 1
Pull up the links list
In NVDA press Insert+F7, in JAWS press Insert+F7, in VoiceOver use the rotor (VO+U → Links). Read each link out of context — if you cannot tell where one goes, it likely fails.
- 2
Scan visually for generic text
Search the page for "click here", "read more", "learn more", "here", and "more". Each one is a candidate failure unless its programmatically-determined context resolves it.
- 3
Check icon and image links
Tab to every icon-only and image link and confirm the screen reader announces a meaningful name — not "link", a filename, or nothing.
- 4
Look for duplicate names
Find links that share an accessible name and verify they go to the same destination. If they differ, give each a unique name or context.
- 5
Verify the accessible name in DevTools
Use the browser's Accessibility panel to read the computed name for each link, confirming aria-label, alt, and visually-hidden text resolve as intended.
Automated scanners flag the obvious cases — empty links, raw-URL text, and known generic phrases — but the judgement call about whether context resolves a link is manual. Practise the screen reader links-list workflow in the Screen Reader Testing guide, and scan a live page with the URL Accessibility Auditor.
Frequently asked questions
What does WCAG 2.4.4 Link Purpose (In Context) require?
WCAG 2.4.4 requires that the purpose of each link can be determined from the link text alone, or from the link text together with its programmatically-determined context — the sentence, paragraph, list item, table cell, or heading it belongs to. The goal is that users, especially screen reader users navigating by a links list, can decide whether to follow a link without having to activate it first. It is a Level A criterion in WCAG 2.0, 2.1, and 2.2, so it applies to virtually every legal and contractual accessibility requirement, including the ADA and Section 508.
Are 'click here' and 'read more' links a WCAG 2.4.4 failure?
Not automatically — but they usually are in practice. "Click here" and "read more" pass 2.4.4 only if the surrounding programmatically-determined context makes the destination clear, for example a 'Read more' link sitting at the end of a paragraph that is genuinely its context. The problem is that screen reader users often navigate by pulling up a list of links stripped of surrounding text, where ten identical 'Read more' entries are meaningless. The most robust fix is descriptive visible text ('Read more about the European Accessibility Act'); the next best is a visually-hidden span or aria-label that extends the name.
How is 2.4.4 different from 2.4.9 Link Purpose (Link Only)?
2.4.4 (Level A) lets you rely on context: the link can be understood from its text plus the sentence, paragraph, or list it sits in. 2.4.9 Link Purpose (Link Only) is a stricter Level AAA criterion that requires the purpose to be clear from the link text by itself, with no context allowed. If you design every link so its text alone is descriptive, you satisfy both at once — which is why writing self-describing links is the recommended approach.
How do I make an icon-only or image link accessible for 2.4.4?
An icon or image link must have an accessible name that conveys its purpose. For an image link, give the <img> meaningful alt text describing the destination (alt="Home"), not the image (alt="logo"). For an icon link built from an SVG or icon font, add aria-label to the link or a visually-hidden text span, and hide the decorative glyph with aria-hidden="true". An icon link with no accessible name fails both 2.4.4 and 4.1.2 Name, Role, Value.
Does aria-label override the visible link text?
Yes — aria-label (and aria-labelledby) completely replaces the visible text as the accessible name, so use it carefully. If you add aria-label, make sure it includes the visible words, otherwise you can break 2.5.3 Label in Name for speech-input users who say the visible label. The safest pattern is to keep descriptive visible text and avoid aria-label entirely, or use a visually-hidden span that extends rather than replaces the visible words.
Do links that open the same URL but have different text need fixing?
No. 2.4.4 is concerned with links whose accessible names are the same but whose destinations differ — those are confusing. Multiple links with different text going to the same place is fine. You can also intentionally give same-destination links the same name; the success criterion specifically warns against the same name pointing to different destinations.