F84: When 'Click Here' Breaks Screen Reader Navigation

Before WCAG 2.0 codified link purpose requirements, "click here" was everywhere — a vestige of early web design that assumed mouse-driven, sighted browsing. Two decades later, the pattern persists in production codebases at a remarkable rate. WCAG Failure F84 (opens in new window) documents exactly why this matters: non-specific link text isn't a minor style issue. It's a navigation system failure for screen reader users.

The contrast worth holding in mind: a sighted user reading a news page sees "Bishops Tickle Darwin's Monkey Theory" followed by a "read more" link — and the visual proximity makes the destination obvious. A screen reader user pulling up their link list sees only "read more." Repeated across a page, that list becomes useless. This is the failure F84 describes, and it maps directly to WCAG 2.4.9 Link Purpose (Link Only) (opens in new window).

The Failure

F84 applies to HTML and describes a specific, common pattern: anchor elements whose text provides no indication of destination, with no supplemental mechanism — like an expand button or aria-label — to fill the gap. The W3C document offers two representative examples.

Example 1 — Inline contextual link:

<a href="file110.html">Click here</a> for more information on the Rocky Mountains.

Example 2 — Article listing with trailing link:

<h2>News headlines</h2>
<p>Bishops Tickle Darwins Monkey Theory</p>
<a href="btdmt.html">read more</a>

In both cases, the surrounding prose provides context — but only if you're reading linearly, in full. The link text, extracted from that context, communicates nothing. That extraction is exactly what screen readers do when building link lists, and it's how many keyboard users navigate: tabbing through focusable elements, hearing only the link label.

This is a failure of WCAG 2.4.9 (opens in new window), the stricter of two link-purpose criteria. (The related criterion, 2.4.4, allows context from surrounding elements to satisfy the requirement — 2.4.9 does not. It requires the link text alone to convey purpose.)

Why This Matters

The W3C document names the mechanism directly: screen reader users commonly open a dialog listing all links on a page to decide where to navigate. This is a core, widely-used feature across JAWS, NVDA, and VoiceOver. When that list returns "click here, read more, click here, more, read more" — it's not just unhelpful, it actively blocks a navigation strategy that many users depend on.

Keyboard-only users face a parallel problem. Tabbing through a page, they hear each link label announced in sequence. A page with ten "read more" links gives them no way to distinguish destinations without reading the surrounding content for each one — defeating the efficiency that keyboard navigation is supposed to provide.

For users with cognitive disabilities, non-specific link text adds unnecessary processing load. "Read more about what?" requires the user to hold context in working memory while scanning back to find the referent. Clear, specific link text eliminates that step entirely.

This isn't an edge case. It's a pattern baked into countless CMS templates, news sites, blog themes, and e-commerce product listings — anywhere a "read more" or "learn more" link appears at the end of a truncated content block.

The Fix

The corrected patterns are straightforward. For the inline case, move the descriptive content into the link itself:

<a href="file110.html">More information on the Rocky Mountains</a>

For the article listing pattern, two approaches work well. The cleanest is descriptive link text:

<h2>News headlines</h2>
<p>Bishops Tickle Darwins Monkey Theory</p>
<a href="btdmt.html">Read more about Bishops Tickle Darwins Monkey Theory</a>

Where design constraints make full visible text impractical, aria-label or aria-labelledby can extend the accessible name without changing visual output:

<a href="btdmt.html" aria-label="Read more about Bishops Tickle Darwin's Monkey Theory">Read more</a>

Or, using aria-labelledby to reference the headline element:

<h2 id="headline-1">Bishops Tickle Darwins Monkey Theory</h2>
<p>Story summary text...</p>
<a href="btdmt.html" aria-labelledby="headline-1">Read more</a>

The aria-labelledby approach is particularly elegant for card and listing patterns — the heading already contains the right text, and you're simply telling the browser to use it as the link's accessible name. No content duplication, no visual change.

Note the scope here: F84 applies specifically to cases where no mechanism exists to make the destination clear. If a design includes a working expand/reveal pattern that lets users see full link text before activating, that mechanism may satisfy the criterion — though the simpler fix is usually just writing better link text.

Applying This

In automated testing: Tools like axe-core and Lighthouse can flag links with generic text ("click here", "here", "more", "read more") — but this is one area where automation catches only the obvious cases. A link reading "details" or "view" may be equally non-specific in context. Our research on automated vs. manual testing documents why automated tools max out around 37% detection on comprehensive audits — link purpose failures are a prime example of what falls through.

In code review: Add link text quality to your PR checklist. Any <a> element whose text is a single generic word should require justification or an aria-label. This is a 30-second check that catches the pattern before it ships.

In design systems: If your component library includes a "card" or "teaser" component with a "read more" link, fix it at the component level. One fix propagates everywhere. That's the operational leverage that makes this a high-priority, low-effort win.

In content workflows: CMS editors frequently introduce this pattern when they override default link text. A brief style guide entry — "link text must describe the destination, not the action" — combined with a content audit filter for known generic strings, can catch this in editorial review.

The compliance picture is also worth understanding in context. WCAG 2.4.9 (opens in new window) is a Level AAA criterion, meaning it's not required for basic WCAG 2.1/2.2 Level AA conformance. However, organizations subject to Section 508 or those targeting AAA compliance — including many federal agencies and higher education institutions — must meet it. And regardless of the conformance level, the underlying accessibility barrier is real. The compliance framework landscape is complex enough without letting technical conformance levels become a reason to leave a fixable barrier in place.

CORS Perspective

Through an operational lens, F84 is a textbook example of a high-impact, low-effort fix — exactly what the CORS framework's operational capacity analysis targets first. The community impact is concrete: screen reader users lose a core navigation mechanism. The risk profile depends on conformance level requirements, but the fix cost is minimal — often a single component change or a content style guide update. Strategically, fixing this at the design system layer rather than page-by-page is the move that makes the improvement sustainable. This isn't a months-long remediation effort. It's a pattern change that, once made at the right level of abstraction, resolves itself across an entire product.