"Click Here" Links: Why They Fail and What to Write Instead

“Click here” links fail because the words carry zero information once they’re separated from the sentence around them — and screen reader users separate them constantly, by jumping link to link or pulling up a list of every link on the page. The fix is simple: make the link text describe the destination, like “view our dinner menu” instead of “click here.” That one habit satisfies a Level A WCAG requirement, and as a bonus, it hands Google exactly the anchor-text signals that “click here” wastes.

Here’s what generic links actually sound like to a screen reader, what the rules require, and before-and-after rewrites for the link patterns small-business sites use most.

What a screen reader user actually hears

Screen readers don’t force people to sit through your whole page. Both of the major Windows screen readers ship a shortcut that pulls every link into a single dialog: NVDA’s Elements List (NVDA+F7) “lists various types of elements, such as links and headings” per the NVDA User Guide, and JAWS has the same feature — Insert+F7, “list all links,” as documented in Deque University’s JAWS shortcut reference. Users also Tab from link to link, hearing only the link text at each stop.

Now picture a typical services page in that list view. The user hears:

Link: click here. Link: click here. Link: learn more. Link: learn more. Link: read more. Link: here.

Every entry is identical or nearly identical, and none says where it goes. As Yale’s accessible links guidance puts it, “these kinds of links can be confusing when a screen reader reads them out of context” — the surrounding sentence that made “click here” sensible to a sighted reader never makes it into the list. If you want the fuller picture of how blind users move through a page, our guide to how screen readers work walks through it.

Patience runs out fast, too. WebAIM’s Links and Hypertext guidance notes that impatient screen reader users “move on to the next link if they cannot understand the purpose of the link after the first few words.” Front-load the meaning or lose the reader.

What WCAG requires for link text

WCAG 2.4.4 Link Purpose (In Context) is the rule, and it sits at Level A — the most basic conformance tier. The W3C’s Understanding document states the requirement: “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.”

That “programmatically determined context” clause is a narrow escape hatch, not a free pass. It means a “read more” link can pass if it sits in the same sentence, list item, or table cell as the words that explain it — context a screen reader can pull on demand. A “click here” floating in a button under a card image usually has no such association and fails outright. The W3C also flags a best practice worth adopting wholesale: links with different destinations should have different link text.

Two sibling criteria round out the picture. WCAG 2.5.3 Label in Name matters the moment you reach for aria-label (more on that below), and the Level AAA version of the link rule (2.4.9) drops the context loophole entirely — link text alone must do the job. You don’t need AAA, but writing as if you did is the easiest habit.

How common is the problem?

Very. According to the WebAIM Million report, an analysis of the top one million home pages run in February 2026, 15.2% of home pages contained ambiguous link text such as “click here,” “more,” or “continue” — up from 13.7% in 2025 — and those pages averaged 5.3 ambiguous links each.

The same February 2026 analysis found empty links on 46.3% of home pages: links with no text at all, usually an icon or image link with no accessible name. An empty link is the “click here” problem taken to its limit — the screen reader can only announce the raw URL or the word “link.” If your social icons or logo link are images, they need alt text that names the destination; our alt text guide covers how to write it.

Before and after: rewriting real link patterns

Generic links cluster in the same handful of spots on small-business sites. Here are the rewrites, using WebAIM’s core rule — the link text should describe the destination, as concisely as possible without sacrificing meaning:

Three patterns from that table are worth calling out. First, “click here to X” almost always shortens to just “X” — WebAIM’s own example trims “click here to access today’s weather” down to “today’s weather,” calling the click-here prefix “unnecessary, even if it precedes a more meaningful phrase.” Second, when a link opens a file, say so in the link text; users deserve to know before a PDF hijacks their browser (and the file itself needs to be usable — see our guide to accessible PDFs). Third, never paste a raw URL as link text: a screen reader will read it character by character.

Can I keep my “Learn more” buttons?

Sometimes — but the honest answer is that every workaround is worse than just writing better visible text. Design teams love uniform “Learn more” buttons on card grids, and there are three ways to handle them, in descending order of quality:

1. Extend the visible text. “Learn more about invisible braces.” Works for everyone, needs no ARIA, and gives search engines a real anchor. This is the fix we make in remediation work whenever the design allows it.
2. Make the card’s heading the link and demote the button to decoration. The heading already says what the card is about, so the link list reads perfectly.
3. Add an aria-label like aria-label="Learn more about invisible braces". This works for screen readers but carries a trap: Yale’s guidance warns that “if the ARIA label does not match the link text at least in part, speech recognition software may not work as a user expects.” A voice-control user says “click learn more” — if your label replaced those words instead of starting with them, nothing happens. That’s the failure WCAG 2.5.3 Label in Name exists to prevent.

If your platform generates the buttons — many Shopify and WordPress themes hard-code “Read more” on every excerpt — the fix lives in the theme template, not the page editor.

The SEO bonus: Google reads your anchors too

Descriptive link text isn’t only an accessibility fix — it’s one of the oldest items in Google’s own playbook. Google’s link best practices documentation lists “click here to learn more” and “read more” as bad anchor text, and its test is nearly word-for-word the screen-reader test: read only the anchor text, out of context, and check whether it’s specific enough to make sense by itself.

Google even supplies the rewrite. Its bad example — “Learn more about our cheese on our website” — becomes “for a full list of cheese available for purchase, see the list of cheese types.” Every descriptive internal anchor tells Google what the destination page is about, which is relevance signal you’re currently spending on the word “here.” Fixing link text is one of the cleanest examples of the overlap we map in our guide to accessibility and SEO: the same edit serves the screen reader user and the crawler.

Five rules for every link you write

1. Describe the destination. The reader should know where the link goes from its text alone — no surrounding sentence required.
2. Front-load the keywords. “Dinner menu (PDF)” beats “View a PDF copy of our current dinner menu.” Screen reader users often decide within the first few words.
3. Cut “click here” entirely. It adds nothing, assumes a mouse, and every rewrite is shorter without it.
4. Give different destinations different text. Ten links that all say “learn more” but go ten places fail the link-list test; identical text should mean identical destinations.
5. Never link a bare URL or an unlabeled icon. Use human-readable text, and give image links alt text that names where they go.

The self-test takes two minutes: open any page, ignore the paragraphs, and read only the links. If they work as a table of contents, you’re done. If they read like “click here, learn more, here, read more,” you’ve found real barriers — the same ones a plaintiff’s screen-reader tester would find.

Want the full list without hunting by hand? Our free accessibility scan flags empty links, ambiguous link text, and unlabeled image links across your site — so you can hand your web person a fix list instead of a guess.