Link Purpose (In Context)

In brief

Screen reader users often pull up a list of all the links on a page and scan it. A list that says "Read more", "Click here", "Read more", "Click here" is useless. Sighted users scan for meaningful links too.

This criterion 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 link context, except where the purpose would be ambiguous to users in general.

What does it cover?

• Link text: Write link text that says where the link goes or what it does. This is the best way to meet the criterion (G91, H30).
• Link context: Context counts when it can be programmatically determined: the sentence, paragraph, list item or table cell containing the link, and the table headers associated with that cell.
• Accessible name techniques: aria-label or aria-labelledby can give a link a more complete name (ARIA8, ARIA7). Visually hidden text can do the same (C7).
• Image links: When an image is the only content of a link, its text alternative is the link text.
• Exception: Links whose purpose is ambiguous to users in general, for example when it is deliberately hidden as in a game where the links say "door 1", "door 2" and "door 3".
• Failures: Providing the context only in content that is not related to the link (F63), and an image-only link with no accessible name (F89).
• Out of scope: The accessible name must also contain the visible text, which is 2.5.3. A stricter version in which the link text alone must make the purpose clear, with no help from context, is 2.4.9 (Level AAA).

Who does it affect?

Screen reader users, who navigate by the list of links. Voice control users, who need unique, speakable link names. People with cognitive disabilities, who need to know what will happen before they act. Anyone scanning a page for links, especially on a small screen.

In the EAA and EN 301 549

The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Understandable link text is part of "operable".

The technical counterpart is the standard EN 301 549, which incorporates WCAG 2.4.4 by reference and turns it into separate clauses for each kind of ICT.

Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.

Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 2.4.4 is the same in WCAG 2.1 and 2.2.

A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.

Directive (EU) 2019/882, EUR-Lex, opens in a new tab

Code examples for the web

1. Descriptive link text

The link text should make sense when read alone.

<a href="/report.pdf">Click here</a> to download the annual report.

<a href="/report.pdf">Download the annual report (PDF, 2 MB)</a>

2. "Read more" links

A list of identical "Read more" links is meaningless. Add the subject to the accessible name.

<h3>Spring sale</h3>
<p>Up to 40% off.</p>
<a href="/sale">Read more</a>

<h3>Spring sale</h3>
<p>Up to 40% off.</p>
<a href="/sale">Read more<span class="visually-hidden"> about the spring sale</span></a>

3. Context from the sentence or list item

Context from the same sentence, paragraph, list item or table cell is acceptable, but a self-explanatory link is better.

<p>Our policy is on the <a href="/privacy">page</a>.</p>

<p>Read our <a href="/privacy">privacy policy</a>.</p>

4. Links in tables

A link can take its context from the table header associated with its cell.

<tr><td>March invoice</td><td><a href="/inv/3">View</a></td></tr>

<tr><td>March invoice</td>
    <td><a href="/inv/3" aria-label="View March invoice">View</a></td></tr>

5. Image links

When an image is the only content of a link, the alt text must say where the link goes.

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

<a href="/cart"><img src="cart.svg" alt="Shopping cart, 3 items"></a>

6. Same text, different destinations

Two links with the same text should lead to the same place. If not, make the names different.

<a href="/uk">Contact</a> <a href="/de">Contact</a>

<a href="/uk">Contact (United Kingdom)</a> <a href="/de">Contact (Germany)</a>

Code examples for mobile

In native apps the same applies to links and to tappable text and buttons. Give each a name that makes sense when read alone, because screen reader users move through them one by one.

iOS (SwiftUI)

import SwiftUI

struct SaleCard: View {
    var body: some View {
        VStack(alignment: .leading) {
            Text("Spring sale").font(.headline)
            Text("Up to 40% off")

            // Avoid: Link("Read more", ...) with no context when read alone
            Link("Read more", destination: URL(string: "https://example.com/sale")!)
                .accessibilityLabel("Read more about the spring sale")
        }
    }
}

Android (Jetpack Compose)

import androidx.compose.foundation.clickable
import androidx.compose.material3.Text
import androidx.compose.runtime.Composable
import androidx.compose.ui.Modifier

@Composable
fun SaleCard(onOpen: () -> Unit) {
    // Avoid: a bare "Read more" that means nothing when read on its own
    Text(
        text = "Read more",
        modifier = Modifier.clickable(
            onClickLabel = "Read more about the spring sale",
            onClick = onOpen
        )
    )
}

How to test

• List the links: Open the screen reader links list (for example NVDA Insert+F7, or the VoiceOver rotor). Does each link make sense on its own?
• Find duplicates: Do several links share the same text but lead to different places?
• Look for vague text: Search for "click here", "read more", "more", "here", "link" and bare URLs.
• Check the context: If a link needs context, is that context in the same sentence, paragraph, list item or table cell?
• Check image links: Does each image-only link have alt text that describes its destination?
• Check voice control: Can you activate each link by saying its visible name, and is the name unique?
• Check mobile: Swipe through the screen with a screen reader. Does each tappable element tell you what it will do?
• Use a checker as a starting point: Automated tools find empty links and some generic phrases, but cannot say whether link text is meaningful.

Common mistakes

• "Click here" and "read more": The classic failure, repeated again and again.
• Bare URLs as link text: A screen reader reads the URL letter by letter.
• Icon links with no name: An image link with empty alt text is announced as "link".
• Context in an unrelated place: A heading far from the link does not count (F63).
• Different destinations, same text: Users cannot tell the links apart.
• aria-label that ignores the visible text: Voice users say what they see, and it does not match (2.5.3).
• A title attribute as the only description: It is not reliably available to all users.
• Over-long link text: A link should be short enough to read in a list.

Sources

• Understanding SC 2.4.4: Link Purpose (In Context) (W3C), opens in a new tab
• G91: Providing link text that describes the purpose of a link (W3C), opens in a new tab
• F63: Failure of Success Criterion 2.4.4 due to providing link context only in content that is not related to the link (W3C), opens in a new tab
• Directive (EU) 2019/882, European Accessibility Act (EUR-Lex), opens in a new tab
• EN 301 549 V4.1.1 (ETSI), opens in a new tab
• The European accessibility standard EN 301 549 has been updated (AccessibleEU), opens in a new tab

Standard version: EN 301 549 V4.1.1 (2026-09), WCAG 2.2. This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official texts of the European Accessibility Act (Directive (EU) 2019/882) and EN 301 549.