Back to reviews and guides

WCAG 2.4.9 Link Purpose (Link Only): Understanding the AAA Link Text Requirement

WCAG 2.4.9 Link Purpose (Link Only) requires that a link shown without sentence context must identify its purpose from its link text or accessible name. This article explains when the rule applies, gives concrete code examples, a decision framework, and a manual testing checklist.

WCAG 2.4.9, called “Link Purpose (Link Only)”, is a AAA success criterion that focuses on link text that appears alone. It requires that when a link is presented without surrounding sentence-level context, the link text itself must identify the link’s purpose so a person using assistive technology can understand where the link goes or what it does.

When this applies

Use this rule when a link is shown on its own or in a list where surrounding content will not be read together with the link. Typical situations include navigation menus, search result lists, related links lists, link-only callouts, and lists of documents or files.

Common patterns that trigger the requirement

  • Lists of links with no paragraph explaining each link
  • Icon-only links with minimal or no accessible name
  • Short link texts such as “Read more” or “Details” when they appear alone

How to make link text meaningful

There are two main approaches. First, make the visible link text descriptive. Second, give the link an accessible name that provides the missing context. Choose the method that works best for your design and content strategy.

Prefer descriptive visible text when practical

Best practice is to change the visible link text so it stands alone. Examples work well in lists and document links.

Bad (not sufficient):

<a href=“/report.pdf”>Read more</a>

Better:

<a href=“/report.pdf”>Read the 2025 annual report (PDF)</a>

When visible text cannot be changed, use an accessible name

If branding, layout, or translation limits visible text, add an accessible name with ARIA or by referencing nearby content. Make sure the accessible name is exposed to assistive technology and not solely placed in a title attribute.

Example using aria-label (escaped):

<a href=“/report.pdf” aria-label=“Download the 2025 annual report PDF”>PDF</a>

Example using aria-labelledby (escaped):

<span id=“rTitle”>2025 annual report</span> <a href=“/report.pdf” aria-labelledby=“rTitle”>Download</a>

Decision framework: change text or add accessible name?

  • If the link appears in a list and wording can be expanded without breaking design, update the visible text.
  • If the link text is a short label used across many pages, prefer an accessible name to avoid duplication work.
  • If the link is an icon-only control, ensure the icon has an accessible name that describes the action or destination.

Testing and verification

Automated tools can flag obvious issues but they miss many link-only contexts. Do manual checks in all important content regions.

  • Keyboard test: navigate through lists and menus with the keyboard and read each link in isolation.
  • Screen reader test: use a screen reader to move through links and confirm the announced text identifies the purpose.
  • Accessibility tree: inspect the accessibility name in the browser accessibility pane to confirm it matches intent.

Common mistakes and fixes

  • Using “Click here” or “Read more” without context. Fix by adding descriptive text.
  • Relying on the title attribute to convey purpose. Fix by using visible text or aria-label/aria-labelledby, because title is not reliably read.
  • Hiding supporting words purely with CSS in a way that removes them from the accessibility tree. Fix by using an accessible name instead or ensure visually hidden text remains available to assistive tech.
  • Icon-only links with no accessible name. Fix by adding an aria-label or aria-labelledby that describes the action.

Practical examples and short cases

Case: a list of PDFs where each link says “Download”. Screen reader users will not know which file each “Download” refers to. Add file name or type to the link text or add an accessible name that includes the file title and format.

Case: small mobile UI where space is tight and link labels are short. Use aria-label to add the full description for assistive technology while keeping the short visual label.

Quick checklist to meet WCAG 2.4.9

  • Scan pages for link-only lists and icon-only links.
  • Ensure each isolated link text indicates purpose by itself.
  • When visible text cannot be usefully expanded, add an accessible name with aria-label or aria-labelledby.
  • Verify with keyboard and a screen reader that each link announces a clear purpose.

Following these steps will make links clearer for people who rely on assistive technology and help you meet the Link Purpose (Link Only) requirement in WCAG 2.4.9.