F65: The Missing Alt Attribute That Breaks Everything

2003: The Web Content Accessibility Guidelines 1.0 required alt text on images. 2008: WCAG 2.0 reaffirmed it under Success Criterion 1.1.1. 2018: WCAG 2.1 carried it forward unchanged. 2023: WCAG 2.2 still lists it — and W3C still needed to publish Failure F65 (opens in new window) documenting how often developers simply leave the attribute out entirely.

Twenty-plus years. One attribute. Still failing.

The Failure

WCAG Failure F65 (opens in new window) describes a specific, unambiguous failure of Success Criterion 1.1.1 Non-text Content (opens in new window): an img element, area element, or input of type image with no alt attribute, no aria-label, no aria-labelledby — nothing. Not an empty alt (which is sometimes correct). Not a missing description. A completely absent text alternative.

The W3C example is deliberately plain:

<img src="../images/animal.jpg">

No alt. No role. No aria-label. Just an image element dropped into the DOM with no signal to assistive technology about what it is or why it's there.

This applies across three element types that teams sometimes overlook:

Why This Matters

The W3C document makes a point that deserves more attention than it typically gets: some assistive technologies attempt to compensate by reading the image file name. This sounds like a reasonable fallback until you look at real-world file naming conventions.

images/nav01.gif. img_3847.jpg. banner_final_v3_REAL.png.

These names are not edge cases — they're the norm in production codebases. And the W3C is explicit: technology specifications do not require descriptive file names, and not all assistive technologies attempt this fallback at all. Relying on it is not a strategy. It's an assumption about behavior that isn't guaranteed.

For screen reader users, a missing alt attribute means one of three outcomes: the file name is announced (often meaningless), the word "image" is announced with no context, or the element is skipped entirely. None of these outcomes tells the user what the image communicates. If that image is a navigation control, a form submission button, or a link target within an image map, the user cannot complete the task.

Keyboard-only users navigating image maps hit area elements with no announced purpose. Users of voice control software cannot target elements that have no accessible name. Users with cognitive disabilities who rely on consistent labeling encounter unpredictable behavior.

This isn't a minor gap in the experience. For certain images — particularly those that function as controls — it's a complete barrier.

The Fix

The corrected pattern depends on the image's role in the page:

Informative image — use descriptive alt text:

<img src="../images/animal.jpg" alt="A red fox standing in snow, facing the camera">

Decorative image — use empty alt to suppress announcement:

<img src="../images/decorative-divider.jpg" alt="">

Image map area — describe the destination or action:

<area shape="rect" coords="0,0,100,50" href="/about" alt="About our organization">

Graphical submit button — describe the action:

<input type="image" src="submit-arrow.png" alt="Submit form">

When ARIA is used instead (must be accessibility-supported):

<img src="../images/animal.jpg" aria-label="A red fox standing in snow">

The W3C's Accessible Name and Description Computation (opens in new window) defines the full priority order browsers and assistive technologies use to derive a text alternative. The alt attribute remains the preferred mechanism for img elements — not because ARIA alternatives are invalid, but because alt has the broadest support across browser and AT combinations.

Applying This

F65 is detectable by automated tools, which makes it one of the more tractable WCAG failures — but our research on automated testing limitations is relevant here. Tools can flag a missing alt attribute reliably. They cannot tell you whether the alt text you've written is accurate, meaningful, or appropriate for context. Automation catches F65. Human review catches the next layer of problems.

For development teams:

• Linting: Configure your HTML linter to flag img elements without alt as errors, not warnings. Tools like axe-core (opens in new window) and Lighthouse (opens in new window) both flag this in automated scans.
• Code review checklist: Add alt attribute presence and quality to your PR review template. Presence is automatable; quality requires a human.
• CMS configuration: If content authors upload images, your CMS should require alt text entry before an image can be published. Make the empty-alt case explicit and intentional, not a default.
• Image map audits: These are frequently missed. Search your codebase for <map> and <area> elements specifically — they often predate modern accessibility awareness and go unreviewed.
• input type="image" search: Run a codebase search for this pattern. Graphical buttons are a common F65 source that automated scans sometimes miss depending on tool configuration.

Teams managing multilingual sites face an additional layer here. A screen reader user who reads Vietnamese encounters the same broken experience as an English-speaking user when alt is absent — but when alt text exists only in English, the barrier shifts. idioma.chat (opens in new window) addresses this directly: it translates not just visible page text but the full accessibility layer, including alt attributes, aria-label values, form validation messages, and dynamically loaded content. This matters because the intersection of language access and disability access is where compliance frameworks typically stop short. Real equal access means the alt text works for a Vietnamese-speaking screen reader user, not just an English-speaking one. The compliance framework analysis we've published shows how organizations treat these as separate workstreams — a structural mistake with real consequences for communities at the intersection.

CORS Perspective

F65 looks like a technical failure, but it's an organizational one. The missing alt attribute is rarely a developer's ignorance of the rule — it's a process gap: no linting enforcement, no code review standard, no CMS guardrail, no training for content authors. From a risk standpoint, this failure is both highly detectable and highly cited in DOJ enforcement actions and private litigation, which means it carries disproportionate legal exposure relative to its technical simplicity. From a community standpoint, the populations most affected — screen reader users, voice control users, users with cognitive disabilities — are also the populations least likely to be in the room when development standards are set. The fix is ten characters of HTML. The systemic change required to make that fix consistent across a large organization is considerably more complex, which is exactly why F65 keeps appearing in audits two decades after the rule was written.