Ambiguous link text: replacing "click here" and "read more"

Updated 2026-10-24 · Altlark guides

"Click here", "read more", "learn more", "more info" and "details" are some of the most common link texts on the web. They make sense when you can see the paragraph around them. But screen-reader users often navigate by pulling up a list of every link on the page (Insert+F7 in NVDA and JAWS, the rotor in VoiceOver). In that list, a page with ten "Read more" links is ten identical, meaningless entries. Voice-control users have the same problem: saying "click read more" matches ten links.

Descriptive link text also helps everyone skim, and it gives search engines better context about the linked page.

Which WCAG criteria apply

• 2.4.4 Link Purpose (In Context), Level A: "The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general."
• 2.4.9 Link Purpose (Link Only), Level AAA is the stricter version: link text alone must be enough.

Note the "in context" part of 2.4.4: a "Read more" link inside a paragraph or list item whose text explains the destination can still meet 2.4.4 at Level A. That's why Altlark reports ambiguous link text as a warning, not an error. It's worth fixing even when it's technically allowed, because the link list experience is still poor.

Bad vs fixed: blog teasers

<h3>How to stop pipes freezing</h3>
<p>Five things to do before the first frost.</p>
<a href="/blog/winter-pipes">Read more</a>

<h3>How to stop pipes freezing</h3>
<p>Five things to do before the first frost.</p>
<a href="/blog/winter-pipes">Read more about stopping pipes freezing</a>

Or, often better, make the heading itself the link and drop the extra one:

<h3><a href="/blog/winter-pipes">How to stop pipes freezing</a></h3>
<p>Five things to do before the first frost.</p>

Bad vs fixed: "click here"

<p>To see our price list, <a href="/prices.pdf">click here</a>.</p>

<p>See our <a href="/prices.pdf">price list (PDF, 200 KB)</a>.</p>

Saying it's a PDF and how big it is helps people decide whether to open it, especially on mobile.

Keeping a short visible label

If the design calls for a short "Learn more" button on every card, you can keep the visible text and add hidden context. The visually hidden text approach keeps the visible words at the start of the accessible name, which helps voice-control users who say what they see:

<a href="/services/drain-cleaning">
  Learn more<span class="visually-hidden"> about drain cleaning</span>
</a>

An aria-label works too, but it replaces the visible text entirely for assistive technology, so make sure it starts with the visible words (WCAG 2.5.3 Label in Name):

<a href="/services/drain-cleaning" aria-label="Learn more about drain cleaning">Learn more</a>

Altlark doesn't flag a short link that has an aria-label or aria-labelledby, on the assumption you've added context that way.

Writing good link text

• Describe the destination or the action: "Download the 2026 price list", "Book a consultation", "Our refund policy".
• Put the meaningful words first.
• Don't include "link" or "click": screen readers already say "link", and not everyone clicks.
• Make links to different places sound different. Two links with the same text should go to the same place.
• Bare URLs as link text (https://example.com/a/b?c=1) are read character by character; use words.

What Altlark checks exactly

For each visible link, Altlark computes its approximate accessible name, lowercases it, strips trailing punctuation and arrows (like "»", "›", "→"), and compares it to a list of common vague phrases: click here, here, click, read more, more, learn more, more info, more information, details, continue, go, this, link, this link, find out more, see more and view more. An exact match with no aria-label or aria-labelledby is reported as "Ambiguous link text" (warning), with the text shown in the report. "Read more about pricing" doesn't match and isn't flagged.

Limits

The list is deliberately short to avoid false alarms, so plenty of vague text ("Info", "Go here", "Start") gets through. And the check can't read the surrounding context, so some flagged links may already meet 2.4.4. Use the results as a to-do list for clearer wording, not as a list of failures.

Testing it yourself

The quickest way to experience the problem is to read your links out of context. With NVDA or JAWS, press Insert+F7 to open the links list; with VoiceOver on a Mac, open the rotor (Control+Option+U) and move to Links. Read down the list: every entry should make sense on its own and be distinguishable from the others. Without a screen reader, a browser extension that lists all links on a page gives you the same view. Pay special attention to blog index pages, product grids and service cards, where repeated "Read more" and "Learn more" links pile up.

Checklist

1. Run the free scan and look for the "Ambiguous link text" warnings.
2. Rewrite each one to name its destination, or link the heading instead.
3. Where the design needs short text, add visually hidden context.
4. Re-scan; then open a links list in a screen reader or a browser extension to read your page's links out of context.