WCAG 1.1.1 Non-text Content: The Foundation That Still Fails

A blind user encounters your homepage. The hero image has no alt text. The icon buttons are unlabeled. The CAPTCHA is audio-only. They leave. This is a Level A failure — the floor, not the ceiling — and it remains one of the most common accessibility violations on the web in 2025.

WCAG 1.1.1 Non-text Content (opens in new window) sits at the base of the entire accessibility standards structure. Level A. Principle 1: Perceivable. It requires that every non-text element — images, icons, audio, video, charts, CAPTCHA, form controls — has a text alternative that serves an equivalent purpose. Get this wrong, and nothing else you do for accessibility fully compensates. It is the criterion that makes the web translatable across sensory modalities: screen readers, braille displays, text-to-speech, and future technologies we haven't built yet.

THE REQUIREMENT

The core obligation is deceptively simple: provide text alternatives for non-text content so that it can be changed into other forms people need — large print, braille, speech, symbols, or simpler language.

But "text alternative" is not a single thing. The requirement branches depending on context:

Content Type	Requirement	Primary Technique
Informative image	Short text description of meaning	H37 (opens in new window) — alt attribute
Decorative image	Empty alt (alt="") so screen readers skip it	H67 (opens in new window) or C9 (opens in new window)
Complex image (chart, diagram)	Short alt + long description	G73 (opens in new window) or G74 (opens in new window)
Functional image (button, link)	Describes the function, not appearance	H36 (opens in new window), H30 (opens in new window)
Audio-only content	Text transcript	G158 (opens in new window)
Video-only content	Text or audio description	G159 (opens in new window)
CAPTCHA	Two different modalities + accessibility alternative	G143 (opens in new window) + G144 (opens in new window)
Form input	Label or accessible name	H44 (opens in new window), ARIA6 (opens in new window)
Image map areas	alt on each <area> element	H24 (opens in new window)

The CAPTCHA case deserves direct attention. The W3C acknowledges this openly: every type of CAPTCHA will be unsolvable by users with certain disabilities. The Working Group's solution — require at least two modalities (visual and audio) — is a pragmatic compromise, not an ideal one. Organizations motivated to go further should consult the W3C's paper Inaccessibility of CAPTCHA (opens in new window) and consider logic puzzles or other CAPTCHA alternatives that don't rely on perceptual discrimination.

WHY THIS MATTERS

The exclusion that happens when 1.1.1 fails is not abstract. It is concrete and immediate.

A screen reader encountering an <img> with no alt attribute will announce the filename — often something like "img_hero_final_v3_USE_THIS_ONE.jpg" — or nothing at all, depending on the browser and assistive technology combination. A blind user has no idea what that image communicates. If the image contains information essential to understanding the page — a data chart, a product photo, a navigation icon — that user is excluded from the content.

Functional images without text alternatives are worse. An icon button with no label, implemented as <button><img src="search.png"></button> with no alt text, gives a screen reader user a button with no announced purpose. They cannot know whether clicking it will search, submit, delete, or do something else entirely. This is not an inconvenience — it is a navigation dead end.

Users with cognitive disabilities benefit from text alternatives in different ways. Clear, consistent alt text reduces cognitive load. Descriptive labels on form controls reduce errors. These aren't edge cases; they represent a substantial portion of the disability community.

For low-vision users who use screen magnification, images rendered as CSS backgrounds (a common failure — F3 (opens in new window)) may not scale or may disappear entirely when high-contrast modes are active. The information simply vanishes.

Automated tools can reliably detect missing alt attributes, but they cannot evaluate whether the alt text provided is meaningful. An alt="image" passes automated checks and fails real users. This is why 1.1.1 compliance requires human judgment, not just tooling.

HOW TO MEET IT

The sufficient techniques are extensive. For most teams, the practical starting point is a decision tree:

Does the image convey information?

• Yes, and it's simple → Use alt attribute with a short description (H37 (opens in new window))
• Yes, and it's complex (chart, diagram) → Short alt + long description via G73 (opens in new window) (adjacent description) or G74 (opens in new window) (description in text near the image)
• No, it's decorative → alt="" (H67 (opens in new window)) or CSS background (C9 (opens in new window))

Is the image a functional element (button, link)?

• Describe what it does, not what it looks like. A magnifying glass icon button gets alt="Search", not alt="magnifying glass".
• For linked images with adjacent text, H2 (opens in new window) allows you to combine the image and text as a single link with alt="".

Is the image a group with redundant text nearby?

• G196 (opens in new window) allows one image in a group to carry the alt text while others use alt="".

For ARIA-based approaches, ARIA6 (opens in new window) (aria-labelledby) and ARIA10 (opens in new window) (aria-labelledby referencing existing text) are valid alternatives when HTML native attributes aren't sufficient — but the HTML-native approach should always be preferred where possible.

The documented failures are equally instructive. F30 (opens in new window) — using a filename or placeholder as alt text — is endemic. F39 (opens in new window) — providing alt text for decorative images — is the opposite problem: screen readers announce meaningless descriptions that interrupt the reading flow. F65 (opens in new window) — omitting the alt attribute entirely — remains the most common single failure across automated audits. F71 (opens in new window) and F72 (opens in new window) address text in images: using images of text rather than actual text, which prevents resizing, reflow, and screen reader access.

APPLYING THIS

Automated testing catches the easy cases: missing alt attributes, empty alt on functional images, images of text. Tools like axe, WAVE, or Lighthouse will surface F65 (opens in new window) reliably. This is a good starting point, but it covers only part of the problem space. Automated tools detect at most 37% of accessibility failures — and for 1.1.1 specifically, the quality of alt text is entirely outside their reach.

Manual review processes that actually work:

• Content audit with alt text review: Export all images and their alt attributes from a CMS. Review in a spreadsheet. Flag filenames, empty strings on functional images, and descriptions that describe appearance rather than meaning.
• Screen reader walkthrough: Navigate key user journeys with NVDA or JAWS. Listen to what gets announced. This surfaces failures that no automated tool will catch.
• Design-phase alt text: Require alt text as a field in design handoff documentation. If designers specify it, developers don't have to guess.
• CMS governance: Configure content management systems to require alt text fields before publication. Many platforms (WordPress, Drupal, Contentful) support this natively.

1.1.1 maps directly to Section 508's equivalent requirement and EN 301 549's 9.1.1.1, so fixing it once satisfies multiple frameworks simultaneously. This is one of the clearest examples of where standards alignment reduces compliance burden rather than multiplying it.

SYSTEMS PERSPECTIVE

From a systems perspective, 1.1.1 failures reveal something beyond technical gaps: they expose where content workflows lack accountability. The community impact is broad — blind users, low-vision users, users with cognitive disabilities, and anyone relying on assistive technology all depend on this single criterion. Operationally, the fix is well within most teams' capacity; the techniques are mature, the tooling exists, and the patterns are documented. Fixing 1.1.1 systematically — through CMS governance, design handoff requirements, and screen reader testing — builds the organizational muscle that makes every subsequent accessibility effort faster and more sustainable.