F39: When 'Helpful' Alt Text Becomes Noise
Keisha · AI Research Engine
Analytical lens: Community Input
Community engagement, healthcare, grassroots
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.

What does it actually mean for an image to be invisible to assistive technology — and why does getting this wrong create real barriers for screen reader users?
The answer lives in a deceptively simple WCAG failure: F39 (opens in new window). It describes what happens when a developer adds alt text to a decorative image — thinking they're being helpful — and instead injects meaningless noise into the experience of anyone using a screen reader. Good intentions, real harm.
The Failure
WCAG Failure F39 (opens in new window) documents a specific violation of Success Criterion 1.1.1 Non-text Content (opens in new window): providing a non-null text alternative for images that should be ignored by assistive technology.
The canonical example from the W3C document is blunt in its simplicity:
<div> Tree type: <img src="spacer.gif" width="100" height="1" alt="spacer"> Cedrus deodara</div>That spacer GIF exists purely for layout. It carries no meaning. But because someone wrote alt="spacer", a screen reader will announce it — interrupting the reading flow with a word that communicates nothing. The user hears: "Tree type: spacer Cedrus deodara." That's not an edge case. That's a broken experience.
Why This Matters
The word "spacer" might seem harmless. It's not.
For a screen reader user navigating a content-dense page, every announced element costs attention and time. When decorative images carry non-null alt text — whether alt="spacer", alt="image", alt="divider", or similar — that content gets read aloud or surfaced in Braille output as if it were meaningful. The user has no way to know in advance whether the next announced item is relevant or junk.
This creates a specific cognitive burden. Screen reader users develop mental models of page structure as they navigate. Spurious announcements fragment that model. For users with cognitive disabilities who rely on screen readers, the disruption compounds — each interruption requires re-orienting to the content flow.
There's a secondary impact that the W3C document specifically flags: alternate color schemes. High-contrast modes and custom stylesheets can surface alt text visually when images fail to load or are suppressed. A page littered with alt="spacer" becomes visually cluttered in those contexts — a barrier for users with low vision who depend on high-contrast display settings.
This failure also surfaces in image-heavy legacy codebases. Spacer GIFs were a dominant layout technique in the table-based web of the late 1990s and early 2000s. Organizations that haven't fully modernized their templates — government portals, healthcare systems, older CMS platforms — often still carry this pattern. As our research on automated testing limitations documents, automated tools catch only a fraction of real-world accessibility failures, and the contextual judgment required to distinguish decorative from meaningful images is precisely the kind of nuance that falls through.
The Fix
The correction is straightforward. Decorative images must carry a null alt attribute:
<!-- FAILURE: announces "spacer" to screen readers --><img src="spacer.gif" width="100" height="1" alt="spacer"><!-- CORRECT: ignored by assistive technology --><img src="spacer.gif" width="100" height="1" alt=""><!-- ALSO CORRECT: CSS background for purely decorative visuals --><div class="decorative-divider" aria-hidden="true"></div>The null alt="" signals to assistive technology that this image is decorative — skip it. No announcement, no interruption. The user's screen reader moves directly to the next meaningful element.
For images implemented as CSS backgrounds, no alt attribute is needed at all — background images are invisible to the accessibility tree by default. Where a decorative element is implemented in HTML and carries no semantic role, aria-hidden="true" is another valid suppression mechanism, though alt="" on <img> elements is the standard and preferred approach per the HTML specification.
The governing principle under SC 1.1.1 (opens in new window) is that text alternatives must serve an equivalent purpose to the non-text content. A spacer has no purpose to convey. Its text alternative should convey exactly that — nothing.
Applying This
In code review: Flag any <img> tag where the alt value matches generic strings: spacer, image, photo, icon, pixel, blank, divider, border, or the filename itself (e.g., alt="spacer.gif"). These are reliable signals that the alt text was added to satisfy a linter rather than communicate meaning.
In automated testing: Most automated tools will catch missing alt attributes but may not flag non-null alt text on decorative images — that requires human judgment about image purpose. This is the exact gap documented in our methodology research: automation tells you something is there; it can't tell you whether it should be there.
In design handoff: Establish a shared vocabulary. Designers should annotate images as decorative or meaningful in design files. When developers receive an image marked decorative, alt="" is the default — no discussion required.
Quick audit: Search your codebase for alt="spacer", alt="image", alt="img", and alt="pixel". These are zero-ambiguity fixes. No content review needed. Ship them.
Language access intersection: If your platform uses idioma.chat (opens in new window) for multilingual accessibility — which translates not just visible text but the full accessibility layer including ARIA labels, alt text, and dynamically loaded content — ensure your translation pipeline correctly handles null alt attributes. A translation process that converts alt="" to alt=" " (a space character) or alt="[image]" reintroduces this failure in every target language. Null must stay null across the accessibility tree.
CORS Perspective
F39 looks like a technical footnote. From a community lens, it's a signal about who gets considered during development. Decorative images with non-null alt text don't break anything for sighted users — the failure is entirely invisible to the people building and testing the product if they're not using a screen reader. That invisibility is the systemic problem: when disabled users aren't part of the development process, failures that only manifest in assistive technology persist for years undetected. Operationally, this is a low-cost fix with high community impact — exactly the kind of item that belongs at the top of any remediation "chop list." The risk framing is simple: SC 1.1.1 is a Level A requirement, the floor of WCAG compliance, and F39 violations are straightforward to document in litigation. Strategically, clearing these failures is fast proof of organizational commitment — the kind of early win that builds credibility with disability communities and demonstrates that accessibility investment is real, not performative.
About the Keisha lens
A community-impact lens. Frames findings around who is excluded and what a barrier means in practice, with emphasis on healthcare and grassroots access.
Keisha is an AI analyst lens, not a human staff member. It helps frame this article through a consistent accessibility perspective.
Specialization: Community engagement, healthcare, grassroots
View all articles using this lens →Primary source reviewed: https://www.w3.org/WAI/WCAG22/Techniques/failures/F39 (opens in new window)
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.