F89: When an Image Link Has No Name, Screen Readers Guess

Marcus
digitalwcagscreen readerslinksimagesautomated testing

Marcus · AI Research Engine

Analytical lens: Operational Capacity

Digital accessibility, WCAG, web development

AI-assisted · Source-linked · Editorially reviewed · Methodology

Trust note

This article was drafted with AI assistance, reviewed against accessibility.chat editorial standards, and should be treated as research and education rather than legal advice. We prioritize primary sources and correct material errors.

Close-up of laboratory equipment with capsules, capturing pharmaceutical analysis.
Photo by Pilan Filmes on Pexels

In the early days of the web, icon-based navigation felt like progress. Skip the words, use a picture — cleaner, faster, more visual. What that era didn't account for was the user who can't see the picture. WCAG Failure F89 documents exactly what happens when that gap goes unfixed: a link containing only an image, with no accessible name, leaves assistive technology with nothing to work with — so it improvises.

That improvisation is the problem.

The Failure

F89 (opens in new window) describes a failure condition where a link contains only non-text content — typically an image — and that link has no accessible name. The Accessible Name and Description Computation (opens in new window) defines how browsers and assistive technologies derive what to call an element. When an image-only link provides neither alt text nor an aria-label, that computation comes up empty.

Three success criteria are directly implicated:

WCAG CriterionLevelWhat It RequiresHow F89 Violates It
2.4.4 Link Purpose (In Context) (opens in new window)AALink purpose determinable from link text or contextNo text = no determinable purpose
2.4.9 Link Purpose (Link Only) (opens in new window)AAALink purpose determinable from link text aloneFails without any surrounding context
4.1.2 Name, Role, Value (opens in new window)AAUI components must have accessible namesLink has no name exposed to the accessibility tree

The source material includes a concrete example worth examining closely. A search results page displays two links to the same destination — one text link reading "Football Scoreboard," one image link using football.gif with alt="":

HTML
<!-- Failure pattern -->
<a href="scores.html">
<img src="football.gif" alt="">
</a>
<a href="scores.html">Football Scoreboard</a>

The null alt attribute seems intentional — the developer reasoned that since a text link already describes the destination, the image link doesn't need duplicate text. The logic is understandable. The execution is wrong.

Why This Matters

A null alt on a standalone image tells the browser: this image is decorative, ignore it. That's correct behavior when an image is genuinely decorative. But when that image is the link — when the <img> is the only content inside <a> — a null alt leaves the link with no accessible name at all.

Screen readers don't silently skip nameless links. They fill the gap. The W3C document describes what actually happens: the screen reader uses heuristics to find nearby text, potentially announcing something like "football dot gif Football Scorecard." The filename becomes the label. That's not a minor inconvenience — it's a broken experience. Users navigating by links hear a string of filenames and guessed text rather than meaningful destinations.

For keyboard-only users, the problem compounds. Tab order exposes both links as separate focusable elements. A user navigating the page encounters what appears to be two links to the same place — one named, one not. That redundancy creates confusion even before the naming failure enters the picture.

Users with cognitive disabilities face a different burden: when link text is unpredictable or inconsistent, the cognitive load of navigation increases. Predictable, descriptive link names are a foundation of usable interfaces, not an accessibility add-on.

The Fix

Two patterns address this, depending on the design intent.

Option 1: Provide an alt attribute on the image

If the image link must remain a standalone element, give the image an alt that describes the link destination:

HTML
<!-- Fixed: image link with descriptive alt -->
<a href="scores.html">
<img src="football.gif" alt="Football Scoreboard">
</a>

The alt text becomes the link's accessible name. Screen readers announce it correctly. The accessible name computation has what it needs.

Option 2: Combine the image and text into a single link (H2)

When both an image and text link to the same destination, the better solution is combining them. The W3C technique H2: Combining adjacent image and text links for the same resource (opens in new window) exists precisely for this scenario:

HTML
<!-- Fixed: combined image and text in one link -->
<a href="scores.html">
<img src="football.gif" alt="">
Football Scoreboard
</a>

Here, the alt is correctly null because the link text provides the accessible name. One link instead of two. No redundancy. No guessing. The accessible name computation finds the text content and uses it.

Option 2 is the architecturally cleaner solution. It reduces the number of focusable elements, eliminates redundant tab stops, and simplifies the link list that screen reader users navigate.

Applying This

This failure is partially detectable by automated tools — but only partially. Automated scanners can flag an <a> element that contains only an <img> with alt="" and no other text content. That's a reliable signal. What automated tools miss is the intent question: was the null alt a mistake, or a developer who thought redundant links were the right pattern?

Our research on automated versus manual testing documents this gap directly — automated tools catch the structural signal, but a human reviewer needs to evaluate whether the design pattern itself is the problem.

For code review, add this check: any <a> whose only child is an <img> should have either a descriptive alt on the image or an aria-label on the link. Lint rules and custom axe-core rules can enforce this. In design systems, icon-only links and button patterns should have accessible name requirements baked into the component spec — not left to individual implementers.

For teams managing large content sites where search results, product listings, or card layouts generate these patterns at scale, the H2 combination approach is worth standardizing in the component library. One pattern, applied consistently, eliminates an entire class of failures.

CORS Perspective

From an operational capacity standpoint, F89 sits in a useful category: high-impact, low-remediation-cost. Adding an alt attribute or combining two links into one is a small code change. The organizational challenge isn't the fix itself — it's detection at scale and prevention going forward. Teams that invest in component-level standards and automated checks in CI/CD pipelines address this class of failure systematically rather than playing whack-a-mole across hundreds of pages. The compliance framework research shows that organizations making durable accessibility progress build these checks into their development workflow, not their remediation queue. F89 is a good place to start that shift.

About the Marcus lens

An operational lens on digital accessibility. Frames findings around what implementation and maintenance actually require — WCAG conformance, engineering effort, and day-to-day web development practice.

Marcus is an AI analyst lens, not a human staff member. It helps frame this article through a consistent accessibility perspective.

Specialization: Digital accessibility, WCAG, web development

View all articles using this lens →

Transparency Disclosure

This article was drafted with AI assistance and reviewed against our editorial methodology. We disclose that process so readers can judge the work clearly.