WCAG 2.4.9: Link Purpose (Link Only)
Screen reader users routinely pull up a list of every link on a page and read it out of context. This criterion asks that each link’s purpose be clear from the link text alone — no surrounding sentence, no nearby heading, no guessing. “Read more” and “Click here” fail on their own; “Read the 2026 accessibility lawsuit report” passes anywhere.
The success criterion, in full
A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general.
Two details matter. “A mechanism is available” means you can either write self-describing links everywhere or offer a setting that switches to fully descriptive links — in practice, nearly everyone does the former. And the exception applies only when a link is ambiguous to everyone, sighted users included, such as a deliberate mystery link in a game.
Who this helps and why
Links are the web’s primary navigation unit, and several groups of users interact with them stripped of all visual context. When every link describes itself, these users move through a site as quickly as anyone else; when links read “here”, “more”, and “this page”, navigation becomes a guessing game.
Screen reader users
The links list (NVDA/JAWS elements list, VoiceOver rotor) shows every link's text with zero surrounding context. Ten 'Read more' entries are indistinguishable.
Speech input users
Users of Dragon or Voice Control activate links by speaking their text. 'Click read the pricing guide' works; three identical 'Click here' targets collide.
People with cognitive disabilities
Self-describing links reduce working-memory load: no need to re-read the paragraph to figure out what a vague link will do before committing to it.
Screen magnifier users
At high zoom only a small slice of the page is visible. A link that depends on a sentence two viewport-widths away is effectively context-free for them too.
How 2.4.9 goes beyond 2.4.4
WCAG has two link-purpose criteria, and the difference between them is exactly one word: context.
- 2.4.4 Link Purpose (In Context) (Level A) — the purpose must be determinable from the link text or from the text plus its programmatically determined context: the enclosing sentence, paragraph, list item, table cell, or a preceding heading.
- 2.4.9 Link Purpose (Link Only) (Level AAA) — the link text alone must identify the purpose. Context no longer rescues a vague link.
Why the stricter bar? Because “programmatically determined context” is only convenient to consume when you are reading the page linearly. A screen reader user who jumps straight into a links list, or tabs from link to link, hears the link text in isolation — retrieving the context means backtracking through surrounding content, which is slow and disorienting. 2.4.9 guarantees the fast path works.
A practical consequence: any page that passes 2.4.9 automatically passes 2.4.4, so teams aiming for the best experience often adopt “every link self-describing” as a content style rule and satisfy both at once. It also reinforces 2.4.6 Headings and Labels, since link text acting as a control label must be descriptive there too.
Pass and fail examples
Code examples
Put the purpose in the visible link text
The strongest technique needs no ARIA at all: link the words that describe the destination instead of a filler phrase.
<!-- ✗ The sentence carries the meaning; the link does not -->
<p>
Our 2026 lawsuit report is now available.
<a href="/reports/2026">Click here</a> to read it.
</p>
<!-- ✓ The link text alone identifies the purpose -->
<p>
Read the
<a href="/reports/2026">2026 accessibility lawsuit report</a>
for the full data.
</p>Extend repeated card links with hidden text
Card grids often want short visible labels. Extend the accessible name with a visually hidden span so each link is unique and self-describing out of context.
<!-- ✗ Three indistinguishable links in the links list -->
<a href="/blog/alt-text">Read more</a>
<a href="/blog/focus-styles">Read more</a>
<a href="/blog/aria-labels">Read more</a>
<!-- ✓ Visible design unchanged; accessible names complete -->
<a href="/blog/alt-text">
Read more<span class="sr-only"> about writing alt text</span>
</a>
<a href="/blog/focus-styles">
Read more<span class="sr-only"> about visible focus styles</span>
</a>If you use aria-label, include the visible text
aria-label replaces the link’s name entirely. To keep speech-input users working (2.5.3 Label in Name), the label must contain the text users can see.
<!-- ✗ Visible text 'More' is not in the accessible name -->
<a href="/pricing" aria-label="Pricing details">More</a>
<!-- ✓ Accessible name starts with the visible text -->
<a href="/pricing" aria-label="More about pricing plans">More</a>Common failures
- 'Click here', 'here', 'more', 'this page', and 'link' as link text — the canonical failures, regardless of how clear the surrounding sentence is.
- Repeated 'Read more' / 'Learn more' links on card or blog listings with no per-link differentiation in the accessible name.
- Raw URLs as link text — long query-string-laden addresses are meaningless when read aloud in a links list.
- File links labeled only by format or action: 'PDF', 'Download', 'View' — without naming which document they open.
- Icon-only links (arrow, chevron, external-link icon) with no accessible name at all, which also fail 2.4.4 and 4.1.2.
- aria-label text that contradicts or omits the visible link text, breaking speech-input activation (2.5.3).
- Linking a whole card via an empty anchor stretched over it, leaving the accessible name empty or set to 'card'.
- Relying on the title attribute to carry the purpose — it is not reliably exposed to keyboard, touch, or screen reader users.
How to test for 2.4.9
- 1
Pull up the links list
Open the screen reader's list of links (Insert+F7 in NVDA/JAWS, the VoiceOver rotor's Links view) or run a browser extension that extracts every link's accessible name. This is exactly the out-of-context view 2.4.9 protects.
- 2
Read each name in isolation
For every entry ask one question: if this were the only thing I could read, would I know where the link goes or what it does? 'Read the returns policy' passes; 'Read more' does not.
- 3
Check duplicates point to the same place
Identical link text is acceptable only when the links share the same destination (a logo and a 'Home' link, say). Identical text pointing at different URLs is an automatic failure.
- 4
Verify accessible names, not just visible text
Inspect links that use aria-label, aria-labelledby, or hidden spans in the browser's accessibility panel. Confirm the computed name is self-describing and includes the visible text.
- 5
Apply the ambiguity exception sparingly
Only exempt links whose purpose is deliberately unknown to every user — mystery or game links. A vague label produced by sloppy copywriting never qualifies for the exception.
Automated tools can list links and flag empty names, but judging whether the words describe the purpose is a human review. Work through the full WCAG 2.2 checklist to cover the neighbouring criteria at the same time.
Frequently asked questions
What does WCAG 2.4.9 Link Purpose (Link Only) require?
It requires that a mechanism is available to allow the purpose of each link to be identified from the link text alone, except where the purpose would be ambiguous to users in general. In plain terms: someone reading nothing but the words inside the link — with no surrounding sentence, heading, or list item — should understand where the link goes or what it does. It is a Level AAA success criterion under Guideline 2.4 Navigable, introduced in WCAG 2.0 and unchanged in WCAG 2.1 and 2.2.
How is 2.4.9 different from 2.4.4 Link Purpose (In Context)?
2.4.4 (Level A) allows the link's purpose to be determined from the link text together with its programmatically determined context — the surrounding sentence, the enclosing list item or table cell, or a preceding heading. 2.4.9 (Level AAA) removes that allowance: the link text alone must do the job. A 'Read more' link inside a paragraph about pricing can pass 2.4.4 because the paragraph supplies context, but it fails 2.4.9 because 'Read more' by itself describes nothing.
What does 'a mechanism is available' mean in 2.4.9?
The criterion is satisfied either by making all link text self-describing by default, or by providing a mechanism — such as a user preference or toggle — that lets users switch to a view where every link is understandable from its text alone. In practice, almost every team simply writes descriptive link text, because maintaining a second 'verbose links' mode is far more work than writing good links in the first place. The mechanism wording exists so that authors who want terse links for general users can still conform.
What is the 'ambiguous to users in general' exception?
If the purpose of a link cannot be known by anyone until they follow it — sighted or not — the link is exempt. The classic example is a link on the word 'guess' in a game, or a mystery link that is deliberately unlabeled for all users equally. The exception covers content where ambiguity is the point, not content where the author simply failed to write a clear label. A 'Click here' link is not ambiguous by design; it is just underspecified, so it does not qualify.
Does an aria-label or visually hidden text satisfy 2.4.9?
Yes. The 'link text' that must describe the purpose is the link's accessible name, so extending it with visually hidden text (a screen-reader-only span) or an aria-label counts. Two cautions: first, if you use aria-label it must include the visible text of the link so speech-input users can still activate it (2.5.3 Label in Name); second, hidden text helps screen reader users but not sighted users scanning the page, so visible descriptive text is the stronger solution when design allows.
Do URLs used as link text pass 2.4.9?
Usually not in any meaningful way. A short, human-readable URL such as example.com/pricing arguably describes its destination, but long tracking-laden URLs read out character by character are unintelligible in a screen reader's links list. Best practice is to always link real words that describe the destination — 'Accessibility.build pricing page' — rather than the raw address, unless the document's purpose is specifically to display the URL itself (for example, in citation formats).
Related Success Criteria
A mechanism is available to bypass blocks of content that are repeated.
Web pages have titles that describe topic or purpose.
Focusable components receive focus in an order that preserves meaning.
The purpose of each link can be determined from link text or context.
More than one way is available to locate a page within a set of pages.