Accessible Links: Text, Purpose, and Common Mistakes

Sighted users read links in the flow of a sentence, so even a vague link like "read more" makes sense from the words around it. Many screen reader users navigate differently: they pull up a list of every link on the page and scan it, or tab from link to link hearing only the link text, stripped of its surrounding sentence. In that mode, a page full of "click here", "read more", and "learn more" is a list of identical, meaningless entries.

This is what WCAG 2.4.4 Link Purpose (In Context) — a Level A requirement — is about: the purpose of each link should be determinable from its text, or at least from its immediate context. The stronger AAA criterion, 2.4.9 Link Purpose (Link Only), asks that the link text work entirely on its own. Writing self-describing link text satisfies both and improves the page for everyone, search engines included.

The fix is almost always the same: move the meaningful words into the link. Instead of describing the destination in the sentence and linking a filler phrase, link the words that describe the destination.

<!-- Avoid: the link text says nothing on its own -->
<p>To see what we charge, <a href="/pricing">click here</a>.</p>
<p>Our new report is out. <a href="/report">Read more</a>.</p>

<!-- Prefer: the link text describes the destination -->
<p>See <a href="/pricing">our pricing plans</a>.</p>
<p>Read the <a href="/report">2026 accessibility report</a>.</p>

A few practical rules keep link text strong:

• Front-load the meaning. "2026 accessibility report" beats "report on accessibility for 2026" — screen reader users often skim the first word or two.
• Keep repeated links consistent. If two links go to the same place, give them the same text. If they go to different places, give them different text — never two "Learn more" links to different pages.
• Do not paste raw URLs as link text. A screen reader will read the whole thing character by character. Use human words.

Links and buttons are not interchangeable. The rule is about what the control does, not how it looks: a link takes you somewhere, a button does something. Choosing the right element gives users the correct keyboard behavior and the correct screen reader announcement for free.

A link that behaves unexpectedly — opening a new tab, starting a download, launching an email client — can disorient users who cannot see the whole screen at once. The fix is not to forbid these, but to warn people before they activate the link.

<!-- Opens a new tab: say so, and add rel="noopener" -->
<a href="https://example.com" target="_blank" rel="noopener">
  Annual report
  <span class="visually-hidden">(opens in a new tab)</span>
</a>

<!-- Downloads a file: name the type and size -->
<a href="/report.pdf" download>
  Download the 2026 report (PDF, 2.4 MB)
</a>

Prefer opening links in the same tab by default — it keeps the back button working and leaves control with the user. Reserve target="_blank" for the rare case where losing the current page would cost the user work (for example, a help link opened from a half-filled form), and always pair it with a visible or hidden "opens in a new tab" cue. Always include rel="noopener" on external new-tab links for security.

A link whose only content is an icon or image has no text for a screen reader to read. Every link needs an accessible name; how you supply it depends on what is inside.

<!-- Icon-only link: label the link, hide the icon from AT -->
<a href="/settings" aria-label="Settings">
  <svg aria-hidden="true" focusable="false">...</svg>
</a>

<!-- Image link: the alt text becomes the link's name -->
<a href="/">
  <img src="/logo.svg" alt="A11yPath home">
</a>

Two things to get right. First, when you label the link with aria-label, mark the decorative icon aria-hidden="true" so it is not announced twice. Second, for an image link the alt text is the link's accessible name, so describe where the link goes ("A11yPath home"), not what the image depicts ("blue diamond logo"). For the full treatment of alt text, see the images and alt text guide.

A link the user cannot see is a link they cannot use. Within a block of text, color alone is not enough to mark a link — WCAG 1.4.1 Use of Color requires a second visual cue, because users with low vision or color blindness may not perceive the color difference. In practice this means an underline on in-text links.

/* In running text, keep the underline — color is not enough on its own */
.prose a {
  color: var(--link);
  text-decoration: underline;
}

/* A visible focus style is non-negotiable — never remove it outright */
a:focus-visible {
  outline: 2px solid var(--focus);
  outline-offset: 2px;
}

Navigation menus and buttons-styled-as-links are the exception: because their position and context already signal that they are interactive, they do not need an underline. The rule is specifically about links embedded in prose, where nothing else distinguishes them from surrounding text. And whatever you do, never remove the focus outline without replacing it — keyboard users rely on it to see where they are. See the focus management guide for accessible focus styling.

• "Click here" / "Read more" / "Learn more". Vague link text that fails out of context. Move the meaning into the link, or extend it with visually hidden text.
• Ambiguous duplicate links. Several "Download" or "View" links on one page that go to different places. Each needs distinguishing text.
• Fake links and fake buttons. <a href="#"> for an on-page action, or <div onclick> for anything. Use the element that matches the behavior.
• Unannounced new tabs. target="_blank" with no warning. Add an "opens in a new tab" cue and rel="noopener".
• Unnamed icon links. An icon or image link with no aria-label or alt. Give every link an accessible name.
• Color-only links in text. No underline, so color-blind and low-vision users cannot spot them. Add a non-color cue.
• Removed focus outlines. outline: none with no replacement. Keyboard users lose their place. Style focus, do not delete it.