When Links Say Nothing: Auditing WCAG 2.4.4 Failures in the Wild

You're navigating a webpage by tabbing through links. Your screen reader announces: "click here." Then "here." Then "read more." You have no idea where any of them go.

This is the daily reality for millions of screen reader users — and it's entirely preventable. The test page at wcagrepo.netlify.app (opens in new window) demonstrates exactly how this pattern fails, with six distinct violations packed into a single demonstration page. The automated analysis identified three link text failures, two landmark structure failures, and one heading hierarchy skip. Let's work through what each means and how to fix it.

The Finding

The analysis of Bug 52: Link — Generic Text (opens in new window) surfaced these violations:

1. Link has non-descriptive text: "click here" (href="/wcag")
2. Link has non-descriptive text: "here" (href="/about")
3. Link has non-descriptive text: "read more" (href="/docs")
4. Heading level skipped: H1 → H3
5. No <nav> landmark found
6. No <header>/banner landmark found

The primary violation is WCAG 2.4.4 Link Purpose (In Context) (opens in new window), a Level A requirement — the lowest, most baseline level of conformance. Failing Level A means the page fails the most fundamental accessibility floor.

Here's the problematic HTML pattern the page demonstrates:

<!-- Bug: Generic link text -->
<p>Learn about accessibility standards <a href="/wcag">click here</a>.</p>
<p>Our company story is <a href="/about">here</a>.</p>
<p>For more information <a href="/docs">read more</a>.</p>

<!-- Bug: Multiple identical link labels -->
<div>
  <h3>Pricing Plans</h3>
  <a href="/pricing">Learn more</a>
</div>
<div>
  <h3>Features</h3>
  <a href="/features">Learn more</a>
</div>

<!-- Bug: Repeated "Download" links -->
<p>Mobile app: <a href="/ios">Download</a></p>
<p>Android app: <a href="/android">Download</a></p>
<p>Documentation: <a href="/docs">Download</a></p>

The heading and landmark failures compound the problem. The page jumps from H1 directly to H3, violating WCAG 1.3.1 Info and Relationships (opens in new window). Missing <nav> and <header> landmarks violate WCAG 1.3.6 Identify Purpose (opens in new window) and undermine the structural scaffolding that assistive technologies rely on to help users orient themselves.

Why This Matters

When a screen reader user pulls up the links list — a standard navigation technique in JAWS, NVDA, and VoiceOver — they see a roster of destinations stripped of surrounding context. "Click here." "Here." "Read more." "Learn more." "Learn more." "Download." "Download." "Download."

None of these tell a user where they're going. Three identical "Download" links with no distinguishing text force users to navigate back to the surrounding paragraph, re-read the context, then return to the link — a frustrating, time-consuming workaround that sighted users never face.

For switch users and people with motor disabilities who expend significant physical effort on each navigation action, this isn't just inconvenient. It's a genuine barrier to equal access.

The missing landmark structure makes this worse. Without <header> and <nav> elements, screen reader users can't jump directly to navigation or skip past it. They're forced to traverse the entire page linearly. The H1→H3 heading skip signals a broken document outline — assistive technologies use heading hierarchy to let users scan and jump through content structure, and gaps in that hierarchy create confusion about how sections relate.

Our research paper Beyond Detection: Why Context Separates Automated Testing from Manual Audits makes a relevant point here: automated tools catch the obvious pattern violations, but the full user impact of these failures often only surfaces through manual testing with actual assistive technology users. The three link failures here are clear-cut catches. The cognitive load they create across an entire site is something only human testing reveals.

Best Practices

Fix generic link text through one of three approaches, in order of preference:

Option 1: Rewrite the visible text (cleanest, benefits all users)

<!-- Before -->
<p>Learn about accessibility standards <a href="/wcag">click here</a>.</p>

<!-- After -->
<p><a href="/wcag">Learn about accessibility standards</a>.</p>

Option 2: Use aria-label to override the visible text

<a href="/pricing" aria-label="Learn more about Pricing Plans">Learn more</a>

Option 3: Use aria-labelledby to combine visible text with context

<h3 id="pricing-heading">Pricing Plans</h3>
<a href="/pricing" aria-labelledby="pricing-heading link-pricing">
  <span id="link-pricing">Learn more</span>
</a>

For the repeated "Download" scenario, aria-label is the most practical fix:

<p>Mobile app: <a href="/ios" aria-label="Download iOS mobile app">Download</a></p>
<p>Android app: <a href="/android" aria-label="Download Android app">Download</a></p>
<p>Documentation: <a href="/docs" aria-label="Download user guide PDF">Download</a></p>

For the structural failures, add the missing landmarks and repair the heading hierarchy:

<header>
  <!-- site header content -->
</header>

<nav aria-label="Main navigation">
  <!-- navigation links -->
</nav>

<main>
  <h1>Bug 52: Link — Generic Text</h1>
  <h2>Bug: "Click Here" Links</h2>  <!-- H2, not H3 -->
  <!-- content -->
</main>

The ARIA Authoring Practices Guide (opens in new window) and W3C's technique for providing descriptive link text (opens in new window) both reinforce Option 1 as the preferred approach — rewriting visible text serves all users, not just those using assistive technology.

Applying This

For development teams, the actionable path here breaks into two tiers.

Quick wins (automatable): Generic link text patterns like "click here", "read more", "here", "learn more", and "download" are detectable by automated tools — axe-core, Lighthouse, and IBM Equal Access Checker all flag them. Add a rule to your CI/CD pipeline that fails builds containing these patterns. This is a low-cost, high-return gate.

Longer-term fix: The real solution is upstream, in your design system and content guidelines. If your component library's card component ships with a hardcoded "Learn more" link, every team using that component inherits the violation. Fix the component once — require that the card component accept a linkLabel prop that generates a contextual aria-label — and you fix it everywhere.

For the landmark and heading issues: run your page through the W3C Nu Html Checker (opens in new window) and a landmark visualizer (the Landmarks browser extension (opens in new window) is useful here). Missing landmarks are often a template-level problem — fix the base template and every page inherits the correction.

As our research on testing methodology demonstrates, automated tools are effective at catching pattern violations like these, but the full scope of a site's accessibility posture requires human judgment. Use automated testing to catch the obvious; use manual testing with screen readers to understand the actual experience.

CORS Perspective

Through the operational capacity lens, generic link text failures are among the highest-ROI fixes in accessibility remediation — they're automatable, often template-level, and frequently solvable with a single design system update rather than page-by-page remediation. The risk dimension is equally clear: WCAG 2.4.4 (opens in new window) is Level A, meaning any audit, complaint, or Title II or Title III enforcement action will flag these immediately. Strategically, framing this as a design system fix — not an accessibility tax — makes the business case straightforward: fix the component once, eliminate the violation everywhere, and build the pattern into your standards so it doesn't recur.