reala11y
Account Free on WP.org See pricing
reala11y GUIDES Link text beyond"click here":writing links that… Jul 12, 2022

July 12, 2022 · reala11y team

Link text beyond "click here": writing links that work out of context

Generic links like "click here" and "read more" fail WCAG 2.4.4. Here's how to write link text that makes sense out of context on WordPress.

Screen reader users rarely read a page top to bottom. One of the most common ways they navigate is by pulling up a list of every link on the page and tabbing through it. NVDA, JAWS, and VoiceOver all offer this. It is fast, and it is how a lot of real browsing happens.

Now picture that list when half the entries say “click here,” “read more,” “learn more,” or “this link.” Stripped of the surrounding sentence, those links mean nothing. The user is left guessing which “read more” leads where.

That is the problem WCAG 2.4.4 Link Purpose (In Context) targets — and it is one of the most widespread, most fixable issues on the web.

What WCAG 2.4.4 actually asks for

The success criterion (Level A, unchanged from WCAG 2.0 in 2018 through WCAG 2.2, the current W3C Recommendation as of 5 October 2023) says the purpose of each link should be clear from its link text, or from the link text together with its programmatically determined context — the sentence, list item, table cell, or heading it sits in.

The phrase “in context” matters. You are not required to cram a full description into every anchor. “Read more” can technically pass if it is genuinely associated with a nearby heading a screen reader can reach. But here is the catch: the isolated links list strips most of that context away. Relying on it is fragile. The robust, user-respecting approach is to make the link text meaningful on its own.

A good test: read the link text aloud with nothing around it. Does it tell you where you’d land?

Patterns that fail (and what to write instead)

A few habits cause most violations:

Generic calls to action repeated down the page.

<!-- Three identical destinations-by-name, three different URLs -->
<a href="/starter">Read more</a>
<a href="/business">Read more</a>
<a href="/agency">Read more</a>

Rewrite each link so it names its own destination: Read more about the Starter plan, and so on. If that feels long in the layout, keep the visible text short and extend it for assistive tech with visually hidden text:

<a href="/starter">Read more<span class="visually-hidden"> about the Starter plan</span></a>

Raw URLs as link text. https://example.com/2025/06/report?utm_source=... is unreadable character by character. Use a human label: the June 2025 traffic report.

“Click here.” Beyond being meaningless out of context, it assumes a mouse — wrong for keyboard, touch, and voice users. Name the action and the target instead.

The same text pointing to different places (or, conversely, different text pointing to the same place). Both confuse the links list. Keep link text and destinations consistent.

Link purpose is not only about visible words. If a link is an image, its alt text is the link text. An icon-only link — a bare magnifying glass, a lone social icon — needs an accessible name via alt, aria-label, or visually hidden text. An empty or decorative-only linked image leaves the user with a link that announces nothing, or worse, reads out a file name.

How this fits a WordPress workflow

On WordPress, generic link text creeps in through everywhere content is authored: “Read more” excerpt links in themes, button blocks copied across pages, plugin-generated “Learn more” rows. It accumulates quietly.

This is exactly the kind of issue automated scanning is good at surfacing but cautious about fixing. A scanner can reliably flag links whose text is a known generic phrase (“click here,” “read more,” “more,” a bare URL). It cannot reliably know the right replacement — that depends on the destination and your intent. So the honest division of labor is: tooling finds the candidates and proposes context; a human confirms the wording.

That is how reala11y treats it. It detects generic and ambiguous link text as part of its WCAG 2.2 checks and points you at each offending link, rather than silently rewriting copy it can’t be sure about. Because reala11y changes the underlying HTML at the source — it is not an overlay widget — a corrected link is corrected for every visitor, every screen reader, and every search crawler, not patched over in a layer they may never see. If you want the broader picture of where 2.4.4 sits among the criteria, the WCAG 2.2 guide lays out the full set.

A reminder worth repeating: automated tools, including ours, detect roughly 30–40% of WCAG issues by criteria. Link-text problems happen to fall in the detectable slice, but conformance overall still needs human review.

The honest takeaway

Good link text is one of the highest-leverage accessibility habits you can build, and it costs nothing but attention. Write every link so it makes sense read on its own. A tool can hand you the list of links that don’t — fixing them well is a five-minute editing pass that makes your site genuinely easier to navigate, not just easier to pass a checker.