F63: When Link Context Lives in the Wrong Paragraph

37%. That's roughly the share of link-purpose failures that automated tools can reliably detect — which means F63 (opens in new window), one of the subtler ways links fail, often slips through entirely. This isn't a failure that announces itself. It looks clean in the DOM. It passes axe. It even looks reasonable to a sighted reviewer skimming the page. And yet, for a screen reader user navigating by links, it's a wall.

The W3C's official failure catalog exists for exactly this reason: to name and document patterns that violate WCAG 2.2 Success Criterion 2.4.4 Link Purpose (In Context) (opens in new window) in ways that are predictable, repeatable, and often invisible to teams relying on automation alone.

The Failure

F63 describes a specific structural problem: the context that explains a link's purpose exists in the page, but in a location that isn't programmatically associated with the link. The standard is precise about what counts as programmatically determined context — the same sentence, paragraph, list item, or table cell as the link, or an ARIA relationship via aria-label or aria-labelledby.

When context lives anywhere else, the link fails — regardless of how obvious the relationship looks to a sighted reader.

The W3C provides two canonical examples. The first is the "Read More" link pattern that appears across news sites, blogs, and government portals everywhere:

<!-- FAILURE: Context is in the preceding paragraph -->
<p>A British businessman has racked up 2 million flyer miles and plans to
travel on the worlds first commercial tourism flights to space.</p>
<p><a href="ff.html">Read More...</a></p>

The second is a layout table where descriptive text sits in one row and the link in the next:

<!-- FAILURE: Context is in a preceding table row, not the same cell -->
<table>
  <tr>
    <td>Play music from your browser</td>
  </tr>
  <tr>
    <td>
      <a href="https://www.example.com/download.htm">
        <img src="download.jpg" width="165" height="32" alt="Download now">
      </a>
    </td>
  </tr>
</table>

In both cases, a sighted user glancing at the page reads the context naturally. A screen reader user tabbing through links hears "Read More" or "Download now" — stripped of meaning.

Why This Matters

Screen reader users frequently navigate pages by pulling up a list of all links — a feature built into virtually every major screen reader. In that mode, links appear without surrounding content. "Read More," "Click Here," "Download Now," and "Learn More" become an undifferentiated list of meaningless labels.

This isn't a minor inconvenience. For a blind user trying to find a specific article, download a specific file, or understand what action a link triggers, ambiguous link text forces a choice: tab through every link and hope context loads, or abandon the task. Neither is equal access.

Switch users, who navigate sequentially and for whom each keystroke carries cost, face a compounded burden. Cognitive disability affects this too — users who rely on predictable, explicit labels are left guessing when context requires inference across structural boundaries.

The failure is particularly common in content management systems where templates separate article teasers from their "Read More" links by design. The visual layout communicates the relationship. The DOM does not.

The Fix

Three reliable remediation patterns exist. The first keeps context and link in the same structural container:

<!-- FIX 1: Move the link into the same paragraph as the context -->
<p>A British businessman has racked up 2 million flyer miles and plans to
travel on the worlds first commercial tourism flights to space.
<a href="ff.html">Read more about his record-breaking travel plans.</a></p>

The second uses aria-label to override the visible link text with a descriptive label:

<!-- FIX 2: Use aria-label to provide full context -->
<a href="ff.html" aria-label="Read more about the businessman's 2 million flyer miles">
  Read More
</a>

The third uses aria-labelledby to programmatically associate the link with existing descriptive content on the page — useful when rewriting templates isn't feasible:

<!-- FIX 3: Use aria-labelledby to reference the heading or description -->
<h2 id="article-headline">Businessman Plans Space Tourism Flight</h2>
<p>A British businessman has racked up 2 million flyer miles...</p>
<a href="ff.html" aria-labelledby="article-headline">Read More</a>

For the layout table pattern, the cleanest fix is restructuring so the description and link share a cell, or using aria-label on the link or image alt text that carries the full context.

The WCAG 2.2 Understanding document for SC 2.4.4 (opens in new window) provides the full normative framework for what constitutes adequate link context.

Applying This

F63 is structurally invisible to most automated tools because the failure is relational, not syntactic. A tool can flag an empty href, a missing alt, or an unlabeled button. It cannot reliably determine that a link's meaningful context sits two DOM nodes away in a sibling element. Our research on automated versus manual testing documents this gap directly — automated tools cap out around 37% detection on failures that require contextual judgment.

Practical catch points for development teams:

• Code review checklist: Flag any link whose visible text is "Read More," "Learn More," "Click Here," "Download," or "View" without an accompanying aria-label or aria-labelledby.
• Template audit: CMS article card templates are the highest-risk location. Review every template that separates teaser text from its corresponding link.
• Link list test: Open a screen reader (NVDA, JAWS, or VoiceOver), pull up the links list for any content-heavy page, and read through it. If any link is ambiguous out of context, F63 is likely present.
• Axe or Deque tools: While they won't catch F63 directly, they surface related issues that signal a team hasn't thought carefully about link context — use those as a prompt for manual review.

The fix is rarely expensive. Template-level changes to CMS article cards can remediate hundreds of instances at once. aria-label additions require minutes per link. The barrier here is usually awareness, not engineering capacity.

This is also an area where compliance framework complexity creates real organizational risk: teams tracking WCAG 2.1 Level AA, Section 508, and EN 301 549 simultaneously may assume automated tooling covers their bases across all three. It doesn't. F63 is a documented failure under SC 2.4.4 (opens in new window), which appears in all three frameworks — but catching it requires human judgment.

CORS Perspective

From a risk and legal priority lens, F63 sits in a deceptive middle zone: it's a documented, named failure against a Level AA success criterion, which means it's squarely within the scope of DOJ enforcement under 28 CFR Part 35 (opens in new window) for Title II entities and the ADA's Title III requirements for public accommodations — yet it's routinely missed in automated audits that organizations cite as compliance evidence. That gap between "we ran the scanner" and "we actually comply" is exactly where legal exposure accumulates. The community impact is direct: blind users and screen reader users encounter this failure on high-traffic content pages where equal access to information is the whole point. Operationally, the fix is low-cost and high-leverage — a template change, not a system overhaul. Strategically, teams that catch F63 through manual auditing demonstrate a testing maturity that holds up under scrutiny far better than an axe report alone.