Link Text That Makes Sense Out of Context

How screen reader users actually navigate

Before we talk about how to write link text, it helps to understand how people actually use links when they can’t see the page.

Screen readers offer a shortcut that most sighted users don’t know exists: pressing a single key (typically the letter L in most screen readers) cycles through all the links on the page, reading them one by one, out of context. Users employ this to scan a page quickly, the way a sighted user’s eye might skim the headings and call-to-action buttons.

If your page has twelve links that say “Read more,” that list is meaningless. The user hears: “Read more. Read more. Read more. Read more…” They can’t tell what any of them lead to.

This is the fundamental problem that link text accessibility tries to solve: every link must be self-describing, because context disappears when you’re navigating by link.

What WCAG says

2.4.4 Link Purpose (In Context) at Level A requires that the purpose of every link can be determined from the link text alone, or from the link text together with its surrounding context (the paragraph, list item, table cell, or heading it sits in).

2.4.9 Link Purpose (Link Only) at Level AAA goes further, requiring link purpose from the link text alone without relying on context. Aiming for this is a good idea even if you’re only targeting AA compliance.

2.5.3 Label in Name (Level A) requires that when a link or button has a visible text label, the accessible name starts with that text. An icon button labeled “Learn more about accessibility” with an aria-label of “Click here” fails this criterion.

Common failures and what to do instead

”Click here” and “Read more”

These are the most widespread link accessibility failures on the web.

<!-- Fails: no meaning out of context -->
<a href="/blog/wcag-compliance">Read more</a>

<!-- Passes: self-describing -->
<a href="/blog/wcag-compliance">Read our WCAG 2.2 compliance guide</a>

The fix is nearly always simple: replace the vague phrase with text that describes the destination or action.

Generic “here” links

“Click here to download the report” fails for the same reason — the link word itself is just “here.”

<!-- Fails -->
<p>For the full findings, click <a href="/report.pdf">here</a>.</p>

<!-- Passes: link text describes what's being linked -->
<p>Download the <a href="/report.pdf">2025 accessibility audit report (PDF)</a>.</p>

Note the PDF indicator in parentheses — this is good practice to inform users that following the link will open a PDF rather than a web page.

Links to the same destination with different text, or different destinations with the same text

Both create confusion. If five navigation links all say “Learn more” but point to different service pages, users can’t predict where they’ll land. Conversely, two different links that say “WCAG compliance guide” but go to different pages are equally confusing.

Icon-only links and buttons

A link or button that contains only an icon — no visible text — must have an accessible name provided through aria-label or aria-labelledby. Without it, screen readers announce the file name of the icon image or nothing at all.

<!-- Fails: announced as "link, graphic" or the SVG filename -->
<a href="/social/twitter">
  <svg><!-- twitter icon --></svg>
</a>

<!-- Passes: aria-label provides the accessible name -->
<a href="/social/twitter" aria-label="QualiBooth on Twitter">
  <svg aria-hidden="true"><!-- twitter icon --></svg>
</a>

The aria-hidden="true" on the SVG prevents screen readers from announcing the SVG title or contents — since the link itself already has a label, the icon content is redundant.

Using aria-label to supplement visible text

When a page has multiple “Download” links and you can’t change the visible text (a design constraint), aria-label can extend the accessible name:

<!-- The visible text is "Download" but the accessible name is the full string -->
<a href="/report-2025.pdf" aria-label="Download 2025 accessibility report PDF">
  Download
</a>

A caution here: WCAG 2.5.3 requires the accessible name to start with the visible text. “Download 2025 accessibility report PDF” starts with “Download” — good. “2025 accessibility report — Download PDF” does not — bad.

Links that open in a new tab

Opening a new tab without warning disorients users, particularly those with cognitive disabilities or screen reader users who may not realize what happened. Indicate new-tab behavior in the link text or with a visually-hidden note.

<!-- Signals new tab behavior visually and to assistive technology -->
<a href="https://example.com" target="_blank">
  View example report
  <span class="sr-only">(opens in new tab)</span>
</a>

When link text works without being obvious

Context can legitimately provide the missing meaning under WCAG 2.4.4. A “Download” link is acceptable if it sits in a table cell whose column header says “Annual Report” and whose row header says “2025.” The context makes the purpose clear.

This is different from a “Read more” link at the end of a standalone paragraph. The paragraph provides context, but “Read more” still fails because the link text could apply to any paragraph — it doesn’t uniquely identify the destination.

Image links

When the link content is an image rather than text, the image’s alt attribute becomes the accessible name of the link. The alt text should describe the destination of the link, not the image itself.

<!-- The alt describes the link destination, not the image appearance -->
<a href="/services/audits">
  <img src="audit-icon.png" alt="Accessibility auditing services">
</a>

If the image is purely decorative and accompanied by visible text in the same link, the image should have alt="" to avoid announcing the same text twice.

A quick audit you can run yourself

Open your page and pull up the list of links using your screen reader (or install the free HeadingsMap or WAVE browser extension to see links extracted from context). Read through the list. If you can’t tell where each link goes from the text alone, it needs work.

The most common fix is adding a <span class="sr-only"> (visually hidden, accessible to screen readers) with additional context, or simply rewriting the link text entirely. Rewriting is always preferred — it often improves usability for everyone, not just screen reader users.

For a thorough review of your site’s links and other WCAG criteria, our manual accessibility audits cover link purpose as part of a broader review by testers who use assistive technology every day.