F67: When Your Long Description Lies to Your Users

1994: the longdesc attribute arrives. 2008: WCAG 2.0 formalizes the requirement for equivalent long descriptions. 2023: WCAG 2.2 publishes F67, a failure technique documenting what teams still get wrong three decades later — writing long descriptions that exist but don't actually work.

The failure is deceptively easy to commit. A developer adds a long description, checks the box, and moves on. The problem: presence isn't equivalence. WCAG 2.2 Failure F67 (opens in new window) documents exactly this — a long description that doesn't serve the same purpose or present the same information as the non-text content it's supposed to replace. That's not an accessibility feature. That's a placeholder that creates the appearance of compliance while leaving users without access to the content.

The Failure

F67 applies to Success Criterion 1.1.1 Non-text Content (opens in new window) and Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded) (opens in new window). Both criteria share the same underlying obligation: non-text content must have a text alternative that presents equivalent information.

The W3C's own example from the F67 document is worth sitting with. An image shows a street map of Olympic venue locations, with icons indicating which sport is held at each venue. The long description reads:

"Map showing the location of each Olympic venue. Skating, hockey and curling are held at the Winter Park Ice Arena, Downhill skiing and jumping are held at Snow Mountain, Gymnastics is held at the JumpUp Arena, Cross Country Skiing is held at the Kilometer Forest."

That description sounds complete. It names venues and sports. But the image conveys spatial information — addresses, relative distances, navigational context. A sighted user can look at the map and understand how far the Ice Arena is from Snow Mountain, or which venues cluster together. The long description gives none of that. It lists names without location. A blind user relying on this description cannot reconstruct what the image actually communicates.

The failure isn't that the description is poorly written. It's that it describes a different thing than what the image shows.

Why This Matters

Users who rely on long descriptions aren't a niche edge case. They include people who are blind or have low vision, people with cognitive disabilities who process text more reliably than complex visuals, and anyone using assistive technology that can't interpret image content directly.

When a long description fails F67, these users face something worse than no description at all: they receive confident-sounding information that is incomplete. They may not know what's missing. A blind user reading the Olympic venue description might reasonably assume they now have what they need to navigate to an event — and only discover the gap when they're standing at the wrong end of a city.

This is the quiet harm of F67 failures. Unlike a missing alt attribute (which screen readers flag as unlabeled or skip), a long description that exists but underdelivers can pass automated testing entirely. The tool sees a description. It can't evaluate whether that description is equivalent. As our research on automated testing limitations documents, automated tools catch at most 37% of real accessibility barriers — and semantic equivalence failures like F67 are exactly the kind that fall into the 63% gap.

The Fix

The correction isn't complicated in concept, though it requires genuine content analysis. The long description must convey the same information the image conveys — not a summary, not a subset, not a related-but-different description.

For the Olympic venue map, a compliant long description would include specific location data: addresses, neighborhoods, or distances from a fixed reference point. The W3C note in F67 is worth emphasizing: long descriptions don't have to be prose. A table can be the right format when the image conveys structured data.

Failing pattern (from the F67 source):

A long description that names venues and sports but omits 
the spatial/location information the map actually conveys.
Example: Map showing Olympic venues. Skating is at Winter 
Park Ice Arena, Downhill skiing at Snow Mountain...
→ Missing: addresses, distances, relative positions, 
  navigational context

Corrected pattern:

A long description that presents equivalent spatial information:
Map of downtown [City] showing Olympic venue locations. 
Winter Park Ice Arena (123 North Ave, 2km from city center): 
Skating, hockey, curling. Snow Mountain (Highway 7, 45km 
northwest): Downhill skiing, jumping. JumpUp Arena 
(456 Sports Blvd, 1.5km from city center): Gymnastics. 
Kilometer Forest (Scenic Route 12, 30km east): 
Cross Country Skiing.
Or as a table:
| Venue | Address | Distance | Events |
|-------|---------|----------|--------|
| Winter Park Ice Arena | 123 North Ave | 2km from center | Skating, Hockey, Curling |

The test is simple to state, harder to apply: could a person using only the long description access the same information as a person viewing the image? If not, the description fails F67 — regardless of how thorough it appears.

Applying This

F67 failures are manual-review problems. No automated tool will catch them reliably. That means teams need a specific review step in their workflow.

In code review: When a long description is added or modified, require the reviewer to identify what information the image conveys — explicitly, in writing — before evaluating whether the description covers it. This forces the comparison rather than assuming the description is adequate.

In content audits: For complex images (maps, charts, diagrams, infographics), build a checklist of information types the image conveys: spatial relationships, quantitative values, sequential steps, comparative data. Verify the long description addresses each category.

In QA testing: Have a tester read only the long description — not the image — and answer questions about the content. If they can't answer what a sighted user could answer from the image, the description is incomplete.

Quick wins: Images that convey simple information (a single data point, a basic icon) are lower risk. Prioritize audit effort on complex images: maps, multi-series charts, process diagrams, photographs with significant contextual detail. These are where F67 failures concentrate.

The compliance framework challenge here is real. Organizations managing multiple standards simultaneously — WCAG, Section 508, EN 301 549 — often treat long description requirements as a single checkbox across all frameworks. Our research on standards fragmentation shows this checkbox mentality is where equivalence requirements break down. The requirement isn't "has a long description." It's "has an equivalent long description." That distinction requires human judgment, every time.

CORS Perspective

Strategically, F67 represents a category of accessibility failure that's particularly difficult to surface through standard compliance workflows — it requires content expertise, not just technical review. For organizations building sustainable accessibility programs, this is an argument for investing in content author training alongside developer training: the person who understands what a map means is often better positioned to write its long description than the developer who implements it. The settlement implementation research we've analyzed shows that organizations focused on technical checkbox compliance consistently miss semantic equivalence failures, which then resurface in subsequent audits or complaints. Getting long descriptions right the first time is a capacity investment — in reviewer skill, in content workflows, in QA process — that pays forward.