Why Does My Site Fail WCAG Link Purpose Checks? Fixing Vague 'Click Here' and 'Read More' Links

Your site fails WCAG link purpose checks when a link's text doesn't tell users where it goes without extra context. "Click here," "read more," and "learn more" are the three biggest offenders — they pass a visual scan but fail Success Criterion 2.4.4 because a screen reader user jumping link to link (or an AI crawler parsing your page) has no idea what any of them actually lead to.

That sounds like a small thing. It isn't. Link text is one of the few places where accessibility and AI visibility point to the exact same fix, and I've audited sites where fixing it moved the needle on both a WCAG score and an AI-citation rate in the same week.

What is WCAG Success Criterion 2.4.4?

Success Criterion 2.4.4 (Link Purpose, In Context) is a Level A requirement under WCAG 2.1. It states that the purpose of each link must be clear from the link text alone, or from the link text combined with its surrounding context — the sentence, the list item, or the paragraph it sits in.

There's a stricter cousin, 2.4.9 (Link Purpose, Link Only), a Level AAA criterion that requires the link text alone to make sense with zero surrounding context. Most sites only need to hit 2.4.4. But if you're building for government, healthcare, or education — sectors where AAA sometimes gets referenced in procurement contracts — it's worth knowing the difference exists.

Here's the part people miss: context counts. A "read more" link is fine under 2.4.4 if the heading right above it says "2024 Tax Filing Deadlines" and a screen reader will announce that heading as part of the link's accessible name. The problem is most "read more" links don't have that connective tissue built in. They're just floating there, same text, fifteen times on a blog archive page.

Why do vague links like "click here" fail accessibility testing?

Screen reader users frequently navigate by pulling up a list of all links on a page — a feature built into JAWS, NVDA, and VoiceOver. When that list is twenty rows of "click here," "click here," "read more," the list is useless. The user can't tell which link goes to your pricing page and which one downloads a 40-page PDF.

WebAIM's annual accessibility analysis of the top one million home pages has, year over year, flagged ambiguous link text among the most common detectable failures sites make — right up there with missing alt text and low contrast. It's not an edge case. It's one of the most widespread, most fixable problems on the modern web.

And it's not just a screen reader issue. Voice control users (Dragon NaturallySpeaking, Voice Control on iOS) often say a link's visible text out loud to activate it — "click learn more" does nothing useful when twelve links on the page share that label. Keyboard-only users tabbing through a page face the same ambiguity, just without an audio cue to warn them.

How does vague link text affect your ADA compliance status?

The ADA doesn't name WCAG directly in its text, but courts and the Department of Justice have consistently pointed to WCAG 2.1 AA as the practical benchmark for "readily accessible" digital content. Link purpose failures show up constantly in ADA demand letters and lawsuits — they're easy for a plaintiff's accessibility auditor to document, because all it takes is a screenshot of a link list full of identical "click here" entries.

If you want the fuller picture of how the law and the standard relate, we've laid it out in ADA vs WCAG: what every business needs to know. Short version: WCAG is the technical standard, ADA is the legal hook, and link text is one of the cheapest line items to fix before anyone notices it's broken.

How does vague link text hurt AI crawlers like ChatGPT and Perplexity?

AI search engines rely heavily on anchor text to understand what a linked page is about before they ever fetch it. When Perplexity or ChatGPT's browsing tool encounters a link labeled "click here," it gets zero semantic signal about the destination. Multiply that across a sitemap and you've got a crawler that has to guess — or just skip the link entirely rather than waste a fetch on an unknown page.

This matters more than most site owners realize, because anchor text doubles as a ranking and citation signal. Google has used anchor text as a relevance signal since the original PageRank paper in the late 1990s, and that principle carried straight into how large language models weigh internal links when they decide which pages deserve a citation in an AI Overview or a ChatGPT Search answer.

I think of it this way: a human skimming your nav can tolerate some ambiguity because they'll click around and figure it out. A crawler building a knowledge graph of your site in one pass doesn't get that luxury. Vague anchors are basically dead ends in the crawler's mental map of your site.

If you want the deeper mechanics of how crawlers parse and cite pages, our guide to AI readability covers the three pillars — crawler access, shared core content, and extractability — and link context touches all three.

What counts as descriptive link text?

Descriptive link text tells the user (and the crawler) what they'll get before they click. The test I use with clients: pull every link off the page into a bare list, no surrounding sentences. Does each one still make sense on its own? If not, rewrite it.

A few before-and-afters:

• "Click here to download our pricing sheet" becomes "Download the 2025 pricing sheet (PDF)" — tells the user the format and the year, which also helps them recognize a stale link later.
• "Read more" on a blog teaser becomes "Read more about our Q3 hiring plans" or, better, the full post title as the link text.
• "Learn more" under a product becomes "See Pro plan features and pricing."
• A bare URL like https://example.com/p?id=4471 becomes a short, human label — "View the client onboarding checklist."

Notice none of these are dramatically longer. Descriptive doesn't mean wordy. It means specific. "Download the pricing sheet" is six words and does the entire job three generic words couldn't.

What if the design really needs short link text?

This is the legitimate exception, and it comes up constantly in card-based layouts — think a grid of blog post previews, each with its own "read more" button under a visible headline. You don't want to repeat the whole headline as visible link text; it looks cluttered and breaks the design.

The fix is to keep the short visible text but give the link a longer accessible name using aria-label, so sighted users see "Read more" while assistive tech and crawlers get the full context:

<a href="/blog/q3-hiring-plans" aria-label="Read more about our Q3 hiring plans">
  Read more
</a>

That one line satisfies 2.4.4 without touching your visual design. It's the single highest-leverage fix on this entire list, honestly — low effort, zero design risk, works for both screen readers and most AI crawlers that read accessible names.

One caveat: don't overuse aria-label as a crutch for every link on the site. Native, visible descriptive text is still the gold standard — it works for everyone, including sighted users who skim quickly and sighted users with cognitive disabilities who benefit from plain, specific wording. ARIA is the patch for tight layouts, not the default strategy. We go deeper on when ARIA actually helps versus when it's papering over bad markup in ARIA labels vs. native HTML.

How do you audit link text across a whole site?

Manually checking every link on a 200-page site isn't realistic, and honestly, it's the kind of task that gets skipped even when teams know better. A few practical approaches:

• Browser extension link lists. Most screen reader testing extensions (and the built-in accessibility inspector in Chrome DevTools) can pull a flat list of every link's accessible name on a page. Scan for duplicates.
• Search your CMS for the phrases. A quick content search for "click here," "read more," and "learn more" across your CMS usually surfaces the worst offenders in minutes.
• Automated scanning. Tools built to check WCAG rules at scale will flag ambiguous link text alongside your other 32 checks — contrast, headings, forms, ARIA — so you're not hunting one issue at a time. AccessKnight's free scan checks link purpose along with the rest of the WCAG 2.1 ruleset and also scores how well AI crawlers can parse the page, which is the part most accessibility-only tools skip entirely.

If you want the full list of what gets checked beyond link text, the WCAG checklist breaks down every rule in plain English with a link to its own fix guide.

Does fixing link text actually move AI citation rates?

I won't pretend there's a clean, universally agreed-upon number here — nobody's published a controlled study isolating anchor text as the single variable in AI citation rates. But the mechanism is well understood: AI engines build an internal map of a site by following and weighing links, and ambiguous anchors weaken every signal downstream of that link, including which pages get surfaced as sources in an AI Overview or cited inline in a ChatGPT Search response.

What I've seen across client audits is a pattern, not a guarantee: sites that clean up link text alongside heading structure and alt text tend to see AI tools describe their pages more accurately, because the crawler has a clearer path through the content in the first place. Link text alone won't get you cited. But it removes one more reason a crawler quietly deprioritizes a page it can't confidently summarize.

Frequently Asked Questions

Does "click here" always fail WCAG?

Not automatically, but it fails in almost every real-world case. Under 2.4.4, "click here" can technically pass if the surrounding sentence makes the destination unambiguous — "Click here to download the 2025 pricing sheet" passes because the sentence provides context. The problem is most "click here" links don't include that context, and the phrase itself adds nothing a screen reader user can act on from a link list.

Is "read more" an accessibility violation?

It's a violation when the same "read more" text appears multiple times on a page without distinguishing context, which is the common case on blog archives and card grids. It's compliant when each instance has a unique, descriptive accessible name — either through surrounding text or an aria-label attribute.

What WCAG success criterion covers link text?

Success Criterion 2.4.4, Link Purpose (In Context), is the Level A requirement most sites need to meet. Success Criterion 2.4.9, Link Purpose (Link Only), is the stricter Level AAA version that requires link text to stand alone with no surrounding context at all.

Do image links need descriptive text too?

Yes. A linked image with no alt text, or alt text like "image123.jpg," fails link purpose checks the same way a text link does — the accessible name of an image link comes from its alt attribute, so that alt text needs to describe the destination, not just the picture. See our guide on alt text best practices for how this overlaps with AI image search.

Can I use aria-label instead of rewriting visible link text?

Yes, and it's often the right call for compact UI elements like card-based "read more" buttons where visible space is limited. Use aria-label to give the link a full, descriptive accessible name while keeping the short visible label intact. Just don't rely on it as a substitute for descriptive text everywhere — visible, specific wording benefits every user, not just assistive tech.

How many links on an average site have this problem?

There's no single definitive percentage, but ambiguous link text consistently ranks among the top handful of detectable failures in WebAIM's annual scan of the top one million home pages, alongside missing alt text and insufficient color contrast. In practice, I rarely audit a site with more than a few dozen pages that doesn't have at least one repeated "read more" or "click here" pattern somewhere.

Next step

Open your own site and search your CMS for "click here," "read more," and "learn more." If you find more than a couple of instances, start with the ones on high-traffic pages — product pages, pricing, your blog archive — since that's where both screen reader users and AI crawlers spend the most time. A free scan at AccessKnight will flag every ambiguous link on the page alongside the rest of your WCAG results and your AI-readability score, so you can see exactly which ones to fix first.