WCAG 2.4.4 Link Purpose (In Context): How to Write Better Accessible Links

This guide explains WCAG 2.4.4 Link Purpose (In Context) and shows how to write link text that users and assistive tech can understand. It includes practical examples, a checklist, and testing tips.

What WCAG 2.4.4 requires

WCAG 2.4.4, titled “Link Purpose (In Context)”, is a Level A success criterion in the WCAG 2.x family. It 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.

Why link purpose matters

People who use screen readers, keyboard navigation or small screens rely on links that make sense out of context. Vague links make it harder to orient, slow tasks and cause mistakes. Clear link purpose helps everyone find content faster.

How to write link text that meets 2.4.4

Prefer visible, descriptive link text. Make the link itself meaningful without forcing the user to read the whole paragraph. When visible text cannot be descriptive, provide programmatic context instead.

Guidelines for good link text

Use the link to describe the destination or action. Example: use “Download 2025 annual report (PDF)” rather than “Download”.
Include file type or format when relevant. Example: “View invoice (PDF)” or “Open spreadsheet (XLSX)”.
Avoid generic phrases: “click here”, “read more”, “more” or repeated “learn more” links without context.
Keep text concise. Aim for one short phrase to express the purpose.

Examples: bad and better

Bad	Better
Click here	Search current job openings
Download	Download 2025 annual report (PDF)

When to provide context instead of changing the visible text

Sometimes the visible design prevents long link text. In those cases give programmatic context that assistive technologies can read. But visible text is preferred over hidden labels.

Options for programmatic context

aria-label: add a concise label if visible text cannot change. Use only when a clear visible label is impossible.
aria-labelledby: reference visible text elsewhere on the page when the link relates to that text.
Alt text for linked images: supply a descriptive alt attribute for an image link.

Do not rely on the title attribute as the only way to communicate purpose. The title is not consistently exposed to assistive technology or mobile users.

Special cases and patterns

If a list of links shares a common heading, the link text can be shorter because the heading provides context. For example a list under “Project files” may contain “Planning.pdf” and “Budget.xlsx”. Still, avoid repeating identical link text that leads to different destinations.

Links that are only icons

Icon-only links must have an accessible name. Prefer visible text next to the icon. If that is impossible, add aria-label or aria-labelledby. Example:

Links that open dialogs or perform actions

When a link triggers an action rather than navigation, label it with the action. Example: “Subscribe to newsletter” or “Open product settings”. If the control is implemented with a link element but behaves like a button, consider using a button element instead and ensure it has an accessible name.

Automated testing and manual checks

Automated tools can find obvious problems, like links that contain only “click here” or empty anchors. They cannot tell whether a link makes sense in its surrounding context. Always follow automated scans with manual inspection using a screen reader and keyboard only.

Simple manual test

Navigate the page using only keyboard Tab. Read each link label in sequence.
Listen with a screen reader to see if link names are meaningful out of context.
Check lists of links so repeated labels do not point to different pages without context.

Checklist for authors and developers

Can the link purpose be determined from the visible link text alone? If yes, good.
If not, does nearby text or a heading provide the missing context? If yes, good.
If neither is possible, add a programmatic name with aria-label or aria-labelledby.
Include file type or action when that matters to the user.
Test with a screen reader and keyboard navigation. Use an automated tool as a first pass only.

Common mistakes and quick fixes

Repeated “Read more” links in a list. Fix: include the article title in each link. Example: “Read more about renewable energy”.
Image links without alt text. Fix: add descriptive alt text such as “View product: Blue ceramic mug”.
Icon-only links that lack aria-label. Fix: add aria-label or visible label next to the icon.
Using title attribute alone to explain a link. Fix: make the visible link text descriptive or add an accessible name.

Example: fixing a document list

Before:

<ul> <li>Annual reports <a href=“/files/report2025.pdf”>Download</a></li> <li>Financials <a href=“/files/fin2025.pdf”>Download</a></li> </ul>

After:

<ul> <li>Annual reports <a href=“/files/report2025.pdf”>Download 2025 annual report (PDF)</a></li> <li>Financials <a href=“/files/fin2025.pdf”>Download 2025 financial statement (PDF)</a></li> </ul>

Practical decision flow

Can you make the visible link text descriptive? If yes, edit the text.
If not, can a nearby heading supply the context? If yes, keep text short but ensure heading is clear.
If not, add a programmatic name with aria-label or aria-labelledby.
Run keyboard and screen reader checks to confirm the link purpose is clear in context.