F13: When Your Alt Text Describes the Picture But Not the Point

Technically correct alt text can still fail two WCAG success criteria at once. F13 — the WCAG 2.2 documented failure (opens in new window) for Success Criteria 1.1.1 Non-text Content (opens in new window) and 1.4.1 Use of Color (opens in new window) — is a case study in how good intentions produce incomplete access. The image gets an alt attribute. The alt attribute gets real words. And disabled users still can't access a core piece of information.

That's worth sitting with for a moment. F13 isn't about missing alt text. It's about alt text that describes the visual surface of an image while leaving out the meaning encoded in color. The lesson here isn't just technical — it's about what "accessible" actually means.

The Failure

The W3C's F13 document (opens in new window) describes a specific, common pattern: an image uses color to convey information, but the text alternative only describes the image's content without capturing what the color communicates.

The official example is a bar chart of sales figures for four employees. The alt text reads:

alt=The following bar chart displays the yearly sales figures for the Sales
Department. Mary sold 3.1 Million; Fred, 2.6 Million; Bob, 2.2 Million;
and Andrew, 3.4 Million. The red bars indicate sales that were below the
yearly quota.

This alt text is doing a lot right. It identifies the chart type, names the employees, and provides the actual figures. But it fails at the finish line. "The red bars indicate sales that were below the yearly quota" tells a sighted user where to look. It tells a screen reader user nothing actionable — because the alt text never specifies which employees fell below quota.

The fix is straightforward:

alt=Bar chart: yearly sales for the Sales Department. Mary sold 3.1M
(above quota); Fred sold 2.6M (below quota); Bob sold 2.2M (below quota);
Andrew sold 3.4M (above quota).

Now the information conveyed by color — quota status — is encoded directly in the text. Color becomes a visual enhancement, not the sole carrier of meaning. That's the standard 1.4.1 Use of Color (opens in new window) requires.

Why This Matters

Three distinct user groups hit this failure in meaningfully different ways.

Screen reader users receive the alt text verbatim. When the alt text says "red bars indicate below quota" without naming who those people are, the user has received a description of a visual cue they cannot perceive — which is functionally useless. They know a color distinction exists. They don't know what it means for them.

Users with color vision deficiency can see the chart but may not distinguish red from other bar colors. If the only way to identify below-quota performance is the red color, these users face the same information gap as someone who can't see the image at all.

Users with low vision who zoom in or use high-contrast modes may see the bars but lose color fidelity in the process. Color-dependent information disappears with the color.

This is why F13 triggers two success criteria simultaneously. 1.1.1 requires that non-text content have a text alternative that serves the equivalent purpose. 1.4.1 requires that color not be the only visual means of conveying information. When color carries meaning that the alt text doesn't capture, you've violated both at once.

The real-world stakes aren't abstract. Sales performance data, medical charts, survey results, maps with color-coded regions, status dashboards — these are the kinds of images where color routinely carries the analytical payload. When that payload doesn't transfer to text, disabled users are excluded from the actual point of the visualization.

Applying This

F13 is almost entirely invisible to automated testing tools. A linter can confirm that an alt attribute exists and contains text. It cannot evaluate whether that text captures color-encoded meaning. This is one of the clearest illustrations of why automated testing alone misses critical barriers — the gap between what tools detect and what users actually need.

Practical steps for development and content teams:

In code review, ask one question for every image with an alt attribute: Does this image use color to distinguish between items or states? If yes, verify the alt text names those states explicitly — not by color, but by what the color means.

In design review, flag any image where color is the primary differentiator. That's a signal that the alt text spec needs to include the semantic content, not just the visual description.

In content workflows, train authors to think about what a chart or diagram concludes, not just what it shows. "Bar chart of sales data" describes the image. "Sales data showing Fred and Bob fell below quota" describes the meaning.

For data visualizations specifically, consider whether the image-based approach is the right one at all. SVG charts with accessible text alternatives, or HTML tables paired with a summary, often serve users better than a raster image with alt text — and they scale across screen sizes and zoom levels without color fidelity loss.

The compliance framework analysis in our research makes a relevant observation: organizations often treat accessibility as a checklist rather than a meaning-transfer problem. F13 is a perfect case study. The checklist item — "image has alt text" — passes. The actual standard — "user can access the same information" — fails.

The Language Access Dimension

There's a compliance intersection here that rarely gets discussed in the same breath: what happens when the alt text is correctly written in English, but the user's primary language is Spanish, Hmong, or Arabic?

Title VI of the Civil Rights Act requires language access for federally funded programs. The ADA (opens in new window) and Section 508 (opens in new window) require accessible content. These are enforced by overlapping agencies — DOJ, HHS, OCR — but almost never audited together. An organization can pass a WCAG audit and still have zero language access infrastructure. A government dashboard that correctly describes quota performance in its English alt text may provide no equivalent access to a Spanish-speaking user with low vision.

This is the gap that tools like idioma.chat (opens in new window) are designed to close. Unlike traditional translation services that handle visible page text, idioma.chat translates the full accessibility layer — ARIA labels, alt text, form validation messages, modal content, and dynamically loaded elements. An image alt text that correctly encodes color-based meaning in English needs to carry that same meaning in translation. Surface-level localization that skips the accessibility layer produces the same failure mode as F13: technically present, functionally incomplete.

Compliance teams need to think about both mandates in parallel, not sequentially. A WCAG-compliant English page is not a fully accessible page if significant portions of the served community don't read English.

CORS Perspective

Viewed through the CORS framework, F13 sits at the intersection of all four pillars — but the Strategic Alignment angle is where organizations most often stall. Leadership approves an alt text policy. The policy says "all images must have alt text." The policy gets implemented. And F13 persists, because the policy addressed the operational requirement (alt text exists) without addressing the community requirement (users can access the meaning). The risk exposure is real — dual SC failure means dual legal exposure — but the strategic fix is cultural, not technical: content teams need to understand that the goal is meaning transfer, not checkbox completion. That shift is faster and cheaper than most organizations assume, and it produces measurably better outcomes for the disabled users who depend on it.