Here's a fun experiment: open any page on your site and count how many links say "click here," "read more," or "learn more." Now imagine reading only those words, stripped of every sentence around them, in a single flat list. That's not a thought experiment for a lot of your visitors — it's literally how they browse.
The fix costs about as much effort as writing "click here" in the first place. Same number of keystrokes, roughly. The difference is that one version tells people what happens next, and the other tells them nothing. Let's fix it, link by link, starting today.
The Stat: WCAG 2.4.4 Link Purpose (In Context) is a real Level A success criterion requiring that a link's purpose be determinable from its link text alone, or from its link text combined with its programmatically-determined context. (Source: W3C WCAG 2.1)
Why "click here" actually breaks things
Sighted users skim a page visually. They see a button, notice its position, glance at the paragraph around it, and click. Context arrives for free because their eyes are doing several jobs at once.
Screen reader users don't get that free context by default — and many of them don't want it. Navigating sentence by sentence through an entire page just to find a link is slow. So screen readers give users a shortcut: a "list all links on this page" view (NVDA and JAWS both call this an elements list, and it's a standard, well-documented feature of assistive technology, not an edge case). Press one key combination, and every link on the page pops up as a flat, alphabetized or sequential list — no surrounding sentences, no headings, no visual layout. Just the link text, one after another.
Now picture that list on a typical content-heavy page:
- Click here
- Click here
- Read more
- Learn more
- Click here
- Read more
That's not a list. That's static. The user has no way to tell which "click here" downloads a PDF, which one starts a newsletter signup, and which one triggers an account deletion. The only way to find out is to back out of the list and read the whole page top to bottom — exactly the slow process the list view exists to avoid. You've taken a feature meant to save time and turned it into a dead end.
This is precisely the failure mode that WCAG 2.4.4 Link Purpose (In Context) exists to prevent. The success criterion doesn't demand poetry — it demands that a link's destination or action be determinable from its own text, or from that text plus context a screen reader can actually reach (like the surrounding sentence or list item). "Click here" fails that test on its own, every time, because "here" refers to nothing without eyes on the paragraph.
The 30-second fix
You don't need a content strategist or a full copy pass. You need one mental habit: before you save, read the link text by itself and ask what it tells you.
Here's the practical version:
- Name the destination or the action, not the gesture. "Click here" describes an action anyone could guess (you click things). "Download the 2026 accessibility report" describes what happens when you do.
- Front-load the unique part. If a page has five "read more" links to five different articles, screen reader users tabbing through by first letter will never distinguish them. Put the article name in the link.
- Avoid vague verbs stacked on vague nouns. "Learn more," "click here," "this page," "read more" — none of these survive being read in isolation. Swap the generic phrase for the specific noun it's hiding: the report, the pricing page, the returns policy.
- Keep it concise, not clever. You're not writing ad copy. "2026 accessibility report" beats both "click here" and an overwrought "Discover our comprehensive deep-dive." Say the thing.
- Test it your own way. Highlight every link on a page and read just the highlighted words in order. If that list makes sense standing alone, you've passed your own version of the 2.4.4 check.
That's it. On an existing page, this is a find-and-fix task you can knock out during a coffee break — most rewrites take less time than reading this sentence twice.
Quick reference: what to swap
| Vague link text (fails on its own) | Descriptive rewrite (passes on its own) |
|---|---|
| Click here | Download the 2026 accessibility report |
| Read more | Read the full case study on retail checkout fixes |
| Learn more | See how link text affects screen reader users |
| This page | View our WCAG 2.4.4 compliance checklist |
| Here | Open the returns policy (opens in new tab) |
Notice that none of the fixes are longer for the sake of length — they're just specific. Specific is the whole trick.
One trap to avoid while you're fixing this
Once teams learn about aria-label, a common overcorrection shows up: someone leaves the visible link text as "Read more" but adds aria-label="Read the full 2026 accessibility report" to make it screen-reader-friendly, without touching what sighted users see. That feels like a fix, but it creates a new, subtler problem. A sighted user working with voice-control software (saying "click read more" to activate a link by its visible label) will fail, because the accessible name the software matches against is the hidden aria-label, not the visible text — the two no longer match. The straightforward fix is almost always better: just change the visible text itself. Reserve aria-label for cases with no visible text at all, like icon-only links, not as a patch over link text you didn't want to rewrite.
A note on icons and buttons
The same rule applies the moment a link is an icon instead of a word — a magnifying glass, an arrow, a hamburger icon acting as a link. Those need an accessible name conveying the same purpose a good link sentence would, via aria-label or visually-hidden text, not just a title attribute that many screen readers skip entirely. The WAI-ARIA Authoring Practices Guide is the reference to bookmark if you're building custom interactive components and want the accessible-name patterns done correctly the first time, rather than guessing and hoping a screen reader interprets your icon the way you intended.
If you want a deeper, technique-by-technique breakdown of how link text interacts with surrounding context, list items, and table cells, WebAIM's guide to links and hypertext walks through the patterns and anti-patterns in more detail than any single blog post can, including exactly how screen readers announce links in different contexts.
Don't stop at links you remember
The tricky part isn't the links you're writing today — you'll catch those in review. It's the hundreds of "click here"s already live on old blog posts, PDFs, footers, and email templates nobody has opened in two years. A one-time manual sweep of a large site is realistically a multi-day project, which is exactly the kind of repetitive audit work that's easy to defer indefinitely.
That's the gap our free scan is built to close: it flags vague link text across your entire site in one pass instead of page by page. If you'd rather see the full list of offenders than hunt for them one link at a time, you can get a free scan that flags vague link text across your site and start fixing the ones that matter most first.