WCAG 2.4.4 Link Purpose (In Context)

What it asks

Links are how people move around. Screen reader users often pull up a list of every link on the page and move through it, out of context. For them "Read more" ten times over is ten links to nowhere. This rule asks that each link’s purpose can be worked out from its text alone, or from its text plus the context the code attaches to it.

That context is specific. It is the sentence or paragraph the link sits in, the list item it belongs to, the table cell it is in and that cell’s headers, or the heading above it. It is not whatever happens to be nearby on screen. A "Read more" link inside a paragraph that names the article passes. A row of "Read more" links under a row of headlines, with nothing in the code tying each link to its headline, does not.

Links with no text at all, such as an icon with no name, fail before context comes into it. There is one exception: a link whose purpose would be unclear to everyone, such as a link in a game of chance, is allowed. The stricter Level AAA version, 2.4.9 Link Purpose (Link Only), does not allow context to help at all. This one is Level A.

Its official name is success criterion 2.4.4 Link Purpose (In Context), at Level A. It was added in WCAG 2.2, under guideline 2.4 Navigable and the principle Operable. The W3C’s normative text says, in part:

“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.”

From WCAG 2.2, W3C. Full explanation: Understanding 2.4.4 Link Purpose (In Context).

Who it helps

Screen reader users, who often move through a page by its links and need each one to make sense on its own or with its immediate context. People with cognitive disabilities, who should not have to follow a link to find out what it was for.

People using voice control, who speak the name of a link to activate it, and cannot say "the third Read more".

What passes and what fails

These pass

• "Read our returns policy", a link whose text says where it goes.
• "Read more" at the end of a paragraph that begins "Our new compost range arrives in March", because the paragraph is the link’s context.
• A list item reading "Cordless mower: see the full specification", where the link text is "see the full specification".
• A table cell containing "Download" in a column headed "Invoice" and a row headed "March 2026".
• An icon-only link with an accessible name, such as a logo link named "Acme Garden Supplies home".

These fail

• A page of news cards where every link reads "Read more" and nothing in the code connects each one to its headline.
• An icon link with no accessible name, such as a bare magnifying glass that opens the search.
• A link whose text is the raw address, such as "https://example.com/p?id=48213".
• "Click here" with the purpose stated in the sentence before it, in a different paragraph.
• Two links side by side with the same text, one to the product page and one to a PDF, with nothing to tell them apart.

Repeated links with the same text that go to the same place are fine. The problem is the same text going to different places with nothing to distinguish them, and different text is the usual fix. For long lists, the context can live in the list item or the table cell rather than in the link, as long as the code ties them together.

How to test it by hand

1. Use a screen reader’s link list, or a browser extension that lists the page’s links, and read the list without looking at the page. Any link you cannot place is a candidate failure.
2. For each one, look at where it sits in the code: its sentence, its list item, its table cell and headers, or the heading above it. If that context explains it, it passes.
3. Check every icon-only link for an accessible name, using the browser’s accessibility inspector.
4. Find links that share the same text and check whether they go to the same place.
5. Note each link that fails and whether it is a pattern repeated across the page, such as a card component.

What automated testing can decide

What a machine can decide

Whether a link has a name at all is a plain fact about the page, and a link with no name is a clear failure. Automated testing can also find links that share a name and compare where they go, and it can collect the context the code attaches to each link, which is what a person needs in order to judge it.

What it cannot

Whether "See details" is enough, given its context, is a question about meaning. Whether two links with the same name go to equivalent places, such as two routes to the same product, needs someone to look. And automated testing cannot know what a visitor is expecting a link to do.

How Dreven handles it

Dreven finds the links on your pages and shows you each one whose purpose is in question, with the link text, the context around it and the page.

A reviewer decides whether the purpose is clear, and the report says how each result was decided and which pages it covers.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 4.1.2 Name, Role, Value (Level A). A link’s accessible name must exist and reach assistive technology.
• 1.1.1 Non-text Content (Level A). An image inside a link needs alt text that says where the link goes.
• 2.4.6 Headings and Labels (Level AA). Headings and labels must describe their content, the same idea for headings and fields.

Questions people ask

All WCAG 2.2 criteria, in plain words