When Helpful Alt Text Becomes Harmful Noise

The static analysis of this test page (opens in new window) passed seven image alt text checks. Every single one. And that's exactly the problem.

Automated tools flagged those images as compliant — they have alt text, after all. But the alt text reads: "Decorative blue star icon for visual enhancement." A screen reader user navigating a product showcase hears that announced before the product name, the price, and the actual content they came for. The star is visual chrome. The announcement is pure noise. This is WCAG Failure F39 (opens in new window) in its most instructive form — a violation that automated testing will pass while creating a genuinely worse experience for the people the standard exists to protect.

This is also a near-perfect illustration of why automated testing catches at most 37% of real accessibility barriers. The tool sees alt attribute present. It moves on. Context — whether that description serves any communicative purpose — is invisible to the scanner.

The Finding

The page contains three distinct failure patterns under WCAG 1.1.1 Non-text Content (opens in new window), all violating the decorative image exception (Failure F39):

Pattern 1 — Descriptive alt on a meaningless icon:

<!-- What the page contains -->
<img src="star.svg" alt="Decorative blue star icon for visual enhancement">

The star accompanies a product listing. It adds no information. Its own alt text admits it's decorative. Yet it gets announced.

Pattern 2 — Described separator:

<img src="separator.svg" alt="Horizontal dotted line separator to divide content sections">

This sits between a maintenance announcement and surrounding content. Screen reader users navigating by heading or landmark don't need a visual separator narrated to them — the document structure should handle that.

Pattern 3 — Three identical ornaments, three identical announcements:

<img src="ornament.svg" alt="Small gold circle decorative ornament">
<img src="ornament.svg" alt="Small gold circle decorative ornament">
<img src="ornament.svg" alt="Small gold circle decorative ornament">

A newsletter header. Three ornaments. Three identical announcements in sequence. A user navigating this content hears the same phrase three times before reaching the actual newsletter title.

The automated scan also identified two structural issues: no <nav> landmark and no <header>/banner landmark. These map to WCAG 1.3.6 Identify Purpose (opens in new window) and WCAG 2.4.1 Bypass Blocks (opens in new window). They're real issues — but the alt text failures are the more instructive story here.

Why This Matters

For a screen reader user, navigating content is a linear, sequential experience. Visual users can skim and skip decorative elements unconsciously. Keyboard and screen reader users cannot. Every announced image is a speed bump.

Consider the product showcase scenario on this page. A user is shopping. They want to know: what is the product, what does it do, what does it cost? Instead, they hear: "Decorative blue star icon for visual enhancement. Premium Laptop Stand. Ergonomic design for better posture. Price: $49.99." The star announcement precedes the product name. It contributes nothing. Multiply this across a product catalog with decorative badges, icons, and separators on every card, and the cognitive overhead becomes substantial.

The newsletter ornament pattern is worse. Three consecutive identical announcements before meaningful content isn't just noise — it's disorienting. Users relying on screen readers develop mental models of page structure. Repeated identical strings disrupt that model and can cause confusion about whether they've navigated somewhere or are stuck in a loop.

It's 2025, and this pattern still appears constantly in production code. The underlying cause is usually good intentions: developers know images need alt text, add descriptive text to every image, and the linter goes green. The purpose of the alt attribute — to provide a text equivalent for images that carry information — gets lost in the implementation.

Best Practices

For decorative images, the correct approach is explicit silence. The WCAG specification is unambiguous: decorative images should be implemented so assistive technology ignores them.

Option 1 — Preferred for <img> elements:

<img src="star.svg" alt="" aria-hidden="true">

Empty alt signals to screen readers that the image is decorative. aria-hidden="true" provides belt-and-suspenders coverage across AT implementations.

Option 2 — For cases where role context matters:

<img src="ornament.svg" alt="" aria-hidden="true" role="presentation">

role="presentation" removes the element from the accessibility tree entirely. Useful for ornamental images inside interactive elements or complex layouts.

Option 3 — Remove from DOM entirely using CSS:

<div class="decorative-separator" aria-hidden="true"></div>

.decorative-separator {
  background-image: url('separator.svg');
  height: 2px;
  /* no alt attribute needed — it's not an img element */
}

For purely ornamental separators and backgrounds, CSS background images are the cleanest solution. They never enter the accessibility tree.

The structural fixes for the missing landmarks are straightforward:

<header role="banner">
  <!-- site header content -->
</header>

<nav aria-label="Main navigation">
  <!-- navigation links -->
</nav>

<main>
  <!-- primary content -->
</main>

Landmarks give screen reader users the ability to jump directly to sections. Without them, every page visit starts from the top. The ARIA Authoring Practices Guide (opens in new window) covers landmark usage in detail.

Applying This

The detection problem here is the real operational challenge. Automated linters will pass images with alt text — even verbose, meaningless alt text. Catching F39 violations requires either manual review or more sophisticated tooling that evaluates whether alt text is appropriate, not just whether it exists.

In code review: Add a checklist item — "Is this image decorative? If yes, does it have alt=""?" It takes five seconds and catches this class of error before it ships.

In design systems: Document a decorative image component with alt="" and aria-hidden="true" baked in. If developers reach for a pre-built <DecorativeIcon> component, the correct pattern is automatic.

In automated pipelines: Tools like axe-core (opens in new window) can flag suspiciously long alt text on images that appear decorative based on context heuristics. It's not perfect, but it narrows the manual review surface. Our research on hybrid testing methodologies explores how to structure this combination effectively.

Quick wins: Search the codebase for alt="Decorative or alt="Icon — these strings are a strong signal that someone wrote descriptive alt text for a decorative element. It's a grep away.

CORS Perspective

Through the CORS framework, this finding lands squarely in Operational Capacity. The community impact is clear — screen reader users in any context where this pattern appears face unnecessary cognitive load and disrupted navigation. The risk exposure under WCAG 1.1.1 (opens in new window) is real but often invisible because automated audits pass these images. Strategically, this is a high-ROI fix: a one-line change per image, catchable in design systems before it ever reaches production. The operational question is whether teams have clear guidance distinguishing informative from decorative images — and whether that guidance is embedded in their workflow, not just their documentation. Most aren't. That's the gap worth closing.