F38: When Silence Isn't Enough for Decorative Images

You've just shipped a redesign. The images look great. A decorative divider, a background flourish, a purely visual separator between content sections. Nobody needs to know what those images are — they carry no information. But your screen reader users are hearing a wall of noise: filenames, URLs, or cryptic auto-generated strings announced for every one of them. The cause is WCAG Failure F38 (opens in new window), and it's one of the most preventable failures in the catalog.

The Failure

F38 (opens in new window) describes a specific violation of Success Criterion 1.1.1 Non-text Content (opens in new window): decorative images in HTML that have neither an alt attribute nor role="presentation". The W3C's official description is precise — this isn't a failure of providing wrong alternative text, it's a failure of providing any signal at all that the image should be ignored.

The problematic pattern is deceptively simple:

<!-- Failure: decorative image with no alt and no role -->
<img src="decorative-divider.png">
<img src="background-swoosh.svg">
<img src="flourish-corner.png">

When assistive technology encounters an image with no alt attribute, it cannot determine intent. Is this informational? Decorative? Functional? Without a signal, many screen readers fall back to announcing the filename or source URL — which is almost always worse than silence.

The fix requires one of two explicit signals:

<!-- Fix Option 1: Null alt attribute -->
<img src="decorative-divider.png" alt="">
<!-- Fix Option 2: role="presentation" -->
<img src="background-swoosh.svg" role="presentation">
<!-- Both together (belt and suspenders approach) -->
<img src="flourish-corner.png" alt="" role="presentation">

Both approaches tell assistive technology: skip this. The null alt is the older, more universally supported pattern. role="presentation" achieves the same result through ARIA semantics. Using both together is redundant but not harmful.

Why This Matters

For a screen reader user, the experience of hitting an unmarked decorative image isn't just annoying — it actively degrades comprehension. Consider a page with six decorative divider images between content sections. Without alt="", a screen reader might announce:

• "divider-blue-gradient-final-v3.png"
• "https://cdn.example.com/assets/img/swoosh-2024.svg (opens in new window)"
• "image"

Six times. Interrupting the actual content. Creating cognitive load that accumulates across every page in a site.

This matters especially for users with cognitive disabilities who rely on screen readers to reduce visual complexity. The noise-to-signal ratio becomes a genuine barrier to comprehension — not just an inconvenience. For users navigating by image (a common screen reader technique to scan page structure), decorative images without proper markup flood the image list with meaningless entries, burying the functional images that actually need attention.

SC 1.1.1 exists to ensure that non-text content either communicates its purpose through text alternatives or is explicitly marked as decorative so it can be safely ignored. F38 is a failure of the second half of that obligation.

The Fix

The corrected patterns are straightforward. The decision tree is what matters:

Does this image convey information?

• Yes → Provide descriptive alt text
• No → Use alt="" or role="presentation"

Is this image purely decorative?

• Yes → alt="" (preferred, most compatible)
• Yes, and you're using modern ARIA patterns → role="presentation"
• Yes, and you want maximum coverage → both

For CSS background images, this failure doesn't apply — background images are already invisible to assistive technology by default. F38 specifically targets HTML <img> elements.

The WCAG Understanding document for SC 1.1.1 (opens in new window) provides detailed guidance on the distinction between decorative, functional, and informational images. That distinction is the judgment call — the markup itself is trivial once the decision is made.

Applying This

For the developer reviewing a pull request, the check is mechanical: any <img> element without an alt attribute is a failure. Full stop. Automated tools catch this reliably — axe-core, Lighthouse, and WAVE all flag missing alt attributes. This is one of the few WCAG failures where automation has genuine teeth.

But here's where teams get tripped up: automated tools flag missing alt attributes, but they cannot determine whether a provided alt attribute is appropriate. An image with alt="decorative swoosh image" passes automated checks but fails the intent of SC 1.1.1 — it's not null, so the screen reader announces it. The fix for F38 is automated-detectable. The broader judgment about which images should be decorative requires human review.

Our research on automated testing methodology confirms this pattern: automated tools catch the structural failure (missing attribute), but context — whether an image is truly decorative — requires human judgment. Teams that rely exclusively on automation will catch F38 but may miss the inverse problem: images marked decorative that actually convey meaning.

Practical steps for development teams:

• In code review: Reject any <img> without an alt attribute. No exceptions. Even if it's "just decorative."
• In design handoff: Designers should annotate which images are decorative in Figma or design specs. Don't leave this decision to developers at implementation time.
• In CMS configuration: If content authors can upload images, the CMS should require an alt field — and provide clear guidance that decorative images should use an empty string, not skip the field.
• In automated CI/CD: Run axe-core or similar in your pipeline. Missing alt attributes should break the build.

The Methodology Paradox research we've published makes the case for hybrid approaches — use automation to catch F38-type structural failures reliably, then layer in manual review for the contextual judgments automation can't make.

The Compliance Picture

The DOJ's 2024 Title II web accessibility rule (opens in new window) formally adopted WCAG 2.1 Level AA as the compliance standard for state and local government websites. SC 1.1.1 is a Level A requirement — the floor, not the ceiling. F38 violations in a government context aren't just a technical debt item; they're a civil rights compliance failure under 28 CFR Part 35 (opens in new window).

For compliance officers reading a DOJ complaint or preparing a transition plan, this is the category of finding that's hardest to defend: it's automated-detectable, the fix is two characters (""), and the failure has been documented in WCAG since version 1.0. The Settlement Trap research we've analyzed shows that organizations often remediate the specific findings in a complaint without building the systematic processes that prevent recurrence. F38 is precisely the kind of failure that recurs when CMS workflows and design handoffs don't encode the alt="" requirement structurally.

CORS Perspective

Through the CORS framework's Risk/Legal Priority lens, F38 sits at an interesting intersection: it's a Level A violation (highest legal priority), it's fully automated-detectable (low operational cost to find), and the fix is trivially low-effort. That combination makes it a strong candidate for the "chop list" — quick wins that address real community impact with minimal organizational investment. The community dimension matters here too: screen reader users aren't a niche population, and the experience of encountering filename noise across an entire site is a genuine barrier to equal participation. Organizations that address F38 systematically — through CI/CD automation and design workflow changes — demonstrate the kind of structural commitment to access that moves compliance from reactive to sustainable.