F42: When a Span Pretends to Be a Link

The <a> element has existed since the earliest days of the web. It carries semantic meaning, keyboard focus, and assistive technology recognition built in — for free. And yet, in 2025, development teams are still reaching for <span onclick> when they need a link. WCAG Failure F42 (opens in new window) documents exactly this pattern, and the fact that W3C needed to write it down — and keep it in WCAG 2.2 — tells you something about how stubborn the problem is.

The Failure

F42 describes what happens when JavaScript event handlers are attached to arbitrary HTML elements — <span>, <img>, <div> — to make them behave like links when clicked with a mouse. The W3C document is precise about the consequence: these elements cannot be tabbed to from the keyboard, do not receive focus like native controls, and are not recognized as links by assistive technology. They won't appear in a screen reader's links list. They won't respond to Enter key activation. They are, in every meaningful sense, invisible to anyone not using a mouse.

The three failure examples in the official document show the pattern at different stages of awareness:

Example 1 — The basic offense:

<span onclick="location.href='newpage.html'">Fake link</span>

No keyboard access. No semantic role. A mouse-only navigation element dressed up as text.

Example 2 — Applied to an image:

<img src="go.gif" alt="go to the new page" onclick="location.href='newpage.html'">

The alt attribute is present — a sign someone was thinking about accessibility — but the fundamental structure is still broken.

Example 3 — Partial fix, incomplete result:

<img src="bargain.jpg" tabindex="0" alt="View Bargains"
  onclick="doNav('bargain.html')"
  onkeypress="doKeyPress('bargain.html')">

This version adds tabindex="0" and a keypress handler. It can now receive focus and respond to Enter. But it still fails — because assistive technology still doesn't identify it as a link. It's a focusable image that does something, not a link.

These examples fail 1.3.1 Info and Relationships (opens in new window), 2.1.1 Keyboard (opens in new window), and 4.1.2 Name, Role, Value (opens in new window). That's a three-criterion failure from a single pattern.

Why This Matters

For a screen reader user, the difference between a real link and a scripted <span> is the difference between navigating a page and hitting a wall. Screen readers like NVDA, JAWS, and VoiceOver expose a virtual links list — a fast-navigation mechanism that lets users jump between links without reading every word on the page. Fake links don't appear there. They're invisible in that context.

For keyboard-only users — including people with motor disabilities who cannot use a mouse — a non-focusable element is simply unreachable. Tab focus skips it entirely. There is no workaround.

Example 3 gets closer, but introduces a different problem: the element announces as an image, not a link. A screen reader user hears "bargain.jpg graphic" or "View Bargains image" — not "View Bargains, link." The behavioral affordance (it navigates somewhere) is completely disconnected from the announced role. That's a 4.1.2 (opens in new window) failure even when keyboard support is technically present.

This is also a cognitive accessibility issue. Users who rely on consistent, predictable interface patterns — including people with cognitive disabilities — depend on links looking and behaving like links. When interactive elements don't signal their purpose through standard semantics, the cognitive load of figuring out what's clickable increases for everyone.

The Fix

The correction is not complicated. Use the element the web platform already provides:

<!-- Instead of this -->
<span onclick="location.href='newpage.html'">Fake link</span>
<!-- Do this -->
<a href="newpage.html">Real link</a>

For the image case:

<!-- Instead of this -->
<img src="go.gif" alt="go to the new page" onclick="location.href='newpage.html'">
<!-- Do this -->
<a href="newpage.html">
  <img src="go.gif" alt="Go to the new page">
</a>

The <a> element gives you keyboard focus, Enter key activation, role announcement, inclusion in the links list, and right-click context menu options — all without a single line of JavaScript. The W3C document notes that ARIA role="link" can be applied to anonymous elements as a remediation path, but explicitly recommends against it as a design approach: native elements exist for a reason, and ARIA should supplement HTML semantics, not replace them.

Applying This

F42 failures are partially detectable by automated tools — axe-core and similar engines can flag elements with click handlers that lack keyboard equivalents or appropriate roles. But as our research on automated testing limits documents, automated tools catch at most 37% of real accessibility barriers. Example 3 above — the version with tabindex and a keypress handler — would likely pass some automated checks while still failing on role semantics.

For code review, the signal to watch for is any onclick attribute on a non-interactive element (<span>, <div>, <img>, <p>). A linting rule that flags onclick on elements without native interactivity catches this class of problem at the source. ESLint with the jsx-a11y plugin includes rules that target this pattern in React codebases.

Design teams can prevent this upstream. When a designer specifies a clickable text element, the default assumption should be <a href>. If the destination isn't known at design time, that's a conversation to have — not a reason to reach for a scripted <span> later.

For teams inheriting legacy codebases, this is a high-priority audit item. Search the codebase for onclick on non-interactive elements. The fix is usually a one-line change per instance. The compliance framework research on our platform documents how organizations get paralyzed by the scope of accessibility debt — but F42 fixes are genuinely fast when the pattern is isolated.

One dimension that often goes unexamined: language access. A site that uses fake links to navigate between language versions — a common pattern in multilingual implementations — breaks that navigation for keyboard users and screen reader users simultaneously. idioma.chat (opens in new window) addresses this by translating not just visible text but the full accessibility layer: ARIA labels, alt text, form validation messages, and dynamically loaded content. That approach only works when the underlying HTML structure is sound. Fake links break the chain before translation even enters the picture.

CORS Perspective

From a strategic alignment standpoint, F42 is a useful case study in technical debt masquerading as a minor issue. Three WCAG success criteria fail simultaneously from a pattern that takes seconds to introduce and minutes to fix — but only if caught early. Organizations that rely primarily on automated testing will miss the semantic failures in Example 3, creating false confidence in their compliance posture. The settlement trap research on this platform shows how organizations that fix surface-level violations without addressing root-cause development practices end up back in the same place. F42 isn't just a bug. It's a signal about whether a team understands what the web platform provides — and whether they've built the review processes to catch it before it ships.