F20: When the Image Changes But the Alt Text Doesn't

For a sighted user, the sales dashboard refreshes automatically — October numbers, fresh charts, current data. For a screen reader user, the same dashboard announces "September sales performance by region" because nobody updated the alt attribute when the chart regenerated. Same page. Same moment in time. Completely different information.

This is WCAG Failure F20 (opens in new window), and it's more common than most development teams realize — precisely because it's invisible to anyone who isn't relying on the text alternative to understand the content.

The Failure

F20 describes a specific breakdown: non-text content changes, but its text alternative doesn't change with it. The W3C's official failure document is unambiguous — if the text alternative can no longer serve as a functional substitute for the non-text content, it fails. Full stop.

The failure implicates two success criteria:

• 1.1.1 Non-text Content (opens in new window) — Text alternatives must convey the same information or function as the non-text content they describe.
• 4.1.2 Name, Role, Value (opens in new window) — User interface components must expose accurate names and values to assistive technologies.

The W3C catalogs three failure patterns, all variations on the same theme:

Applicability: every technology. HTML, native apps, PDF, SVG — if non-text content can change and a text alternative can go stale, F20 applies.

Why This Matters

The failure is subtle in a way that makes it dangerous. A missing alt attribute triggers automated testing tools. Stale alt text doesn't — the attribute is present, it has a value, the automated check passes. What the tool cannot know is whether "September sales by region" accurately describes what's now an October chart.

This is precisely the gap documented in Beyond Detection: Why Context Separates Automated Testing from Manual Audits — automated tools cap out around 37% detection of real accessibility barriers. F20 violations live firmly in the 63% that only human review and contextual testing can catch.

For screen reader users, the consequences are concrete. A financial analyst using JAWS to review quarterly data gets incorrect figures. A job seeker on a company homepage gets a description of an image that was replaced three weeks ago. A user with low vision relying on alt text as a fallback for a slow-loading image gets information that no longer corresponds to anything on the page.

The 4.1.2 dimension matters too — this isn't just an alt text problem. When scripts update image sources without updating accessible names, the programmatic relationship between the UI component and its announced value breaks. Assistive technologies report what the DOM says. If the DOM is lying, so is the AT.

The Fix

The failing pattern — script updates the image source but leaves alt untouched:

<!-- Initial state -->
<img id="sales-chart" src="chart-september.png" alt="September sales performance by region">
<script>
  // Later, the chart is updated...
  document.getElementById('sales-chart').src = 'chart-october.png';
  // alt attribute never updated — F20 violation
</script>

The corrected pattern — alt text updated in the same operation as the image source:

<img id="sales-chart" src="chart-september.png" alt="September sales performance by region">
<script>
  function updateChart(month, src, description) {
    const chart = document.getElementById('sales-chart');
    chart.src = src;
    chart.alt = description; // Updated atomically with the visual change
  }
  updateChart('October', 'chart-october.png', 'October sales performance by region, showing 12% increase over September');
</script>

For dynamic content that changes frequently — rotating homepage images, live data visualizations, real-time dashboards — the principle is the same: the text alternative is part of the content, not metadata about it. Any update pipeline that touches the visual content must treat the text alternative as an equal component of that update.

For ARIA-based components where aria-label or aria-labelledby provides the accessible name, the same rule applies:

// If using aria-label instead of alt:
element.setAttribute('aria-label', 'October sales performance by region');

Applying This

F20 failures hide from automated testing, which means teams need deliberate process controls to catch them.

In code review: Any pull request that updates image src attributes — especially through JavaScript — should trigger a reviewer question: does the corresponding alt attribute update in the same commit? Make this a checklist item, not an afterthought.

In QA testing: For any page with dynamic content (carousels, dashboards, data visualizations, personalized content), manual testing should include verifying that text alternatives match the current state of the content — not just that alt attributes exist. Run a screen reader through a full content cycle, not just the initial page load.

In design and content workflows: When content teams update images — seasonal homepage banners, refreshed marketing visuals, updated infographics — the alt text update should be a required field in the CMS workflow, not optional metadata. If your CMS allows image replacement without requiring alt text review, that's a process gap.

In component architecture: If your front-end framework handles dynamic content, build alt text as a required prop alongside src. A React component that accepts imageSrc without requiring imageAlt as a parallel prop is structurally set up to produce F20 violations at scale.

The compliance framework complexity documented in The Compliance Framework Paradox is real — but F20 is one of those cases where the fix is genuinely straightforward once teams understand the pattern. The hard part isn't the code. It's building the organizational habit of treating text alternatives as living content rather than static labels.

CORS Perspective

From a Risk/Legal Priority lens, F20 sits in a frustrating category: violations that are legally meaningful but nearly invisible to standard compliance audits. Both 1.1.1 (opens in new window) and 4.1.2 (opens in new window) are core WCAG success criteria — failures here are failures under Section 508, Title II, and Title III alike — yet automated scanning will report these pages as passing. Organizations relying solely on automated tools to demonstrate compliance are carrying legal exposure they cannot see, which is precisely the scenario The Methodology Paradox warns against. The strategic fix is institutional: dynamic content must be governed by process, not just code.