WCAG 1.1.1 Non-text Content: how to pass it

This page goes past the official wording. It covers how often the criterion fails in the wild, each of the six exceptions with what it still demands, real failing and passing markup, a step-by-step test you can run today, the edge cases that fool automated checkers, and exactly which parts of 1.1.1 GotAlt's tools can and cannot check.

What WCAG 1.1.1 requires

Success criterion 1.1.1 is the first criterion in WCAG and sits at Level A, the minimum level. It has been part of WCAG since WCAG 2.0 (December 11, 2008), and later versions keep it, so it is in WCAG 2.2 today. Its core sentence asks that all non-text content presented to the user has "a text alternative that serves the equivalent purpose" (W3C, WCAG 2.2).

The WCAG glossary defines non-text content as content that is not a sequence of characters a program can determine, or where the characters do not express something in human language, and it names ASCII art, emoticons, leetspeak and images of text as examples. On a typical website that means:

• <img>, <input type="image"> and <area> elements;
• inline <svg> and icon fonts that carry meaning, such as a cart icon or a warning symbol;
• <canvas> drawings, charts, maps and infographics;
• CSS background images that carry information, such as a "New" badge drawn as a picture;
• audio and video, which also have their own criteria under guideline 1.2.

The alternative must be tied to the item in code. The glossary defines a text alternative as text that is programmatically associated with the non-text content, or referred to from text that is. In practice that is an alt attribute, an aria-label, an aria-labelledby reference, or a short alternative that points to a longer description nearby. A caption a sighted visitor can see, but which nothing in the markup connects to the image, does not count on its own.

Because 1.1.1 is Level A, it sits inside every WCAG target the laws in our register name: WCAG 2.1 AA for the ADA Title II web rule, WCAG 2.0 A and AA for Section 508, and WCAG 2.1 AA through EN 301 549 for the European Accessibility Act. Our laws hub covers each one. This page explains a technical standard and is not legal advice.

How often 1.1.1 fails in the wild

WebAIM's annual scan of the top million home pages is the standard reference for real-world failure rates. In the 2026 WebAIM Million (data collected February 2026):

• Missing alternative text was found on 53.1% of home pages, second only to low contrast text (83.9%; see our WCAG 1.4.3 guide).
• The average home page had 66.6 images, and 16.2% of all home page images, about 10.8 per page, had no alternative text at all (WebAIM does not count alt="" here).
• 45% of the images missing alternative text were linked images, which WebAIM notes left those links not descriptive.
• Of the images that did have alternative text, 10.8% had questionable or repetitive text, with examples such as "image", "graphic" and "blank".

Every one of those figures counts something software can detect from code. None of them measures whether alt text that is present is true of its picture, so the real failure rate for 1.1.1 is likely higher. Our guide to the most common accessibility errors puts these numbers next to the other five categories WebAIM reports.

The six exceptions, and what each still requires

The criterion lists six situations where a full equivalent is not required or not possible. None of them lets you provide nothing: each one still asks for something specific. The middle column paraphrases the normative text, which W3C's Understanding 1.1.1 explains case by case; the last two columns are our worked examples.

The exceptions are narrow. A product video still needs its identification, and its captions are a separate requirement. A CAPTCHA that offers only a picture fails even when its alt text is perfect, because the second half of that exception asks for another sensory route.

Decorative images: what alt="" actually does

An empty alt attribute is not the same as a missing one. W3C's images tutorial notes that when the attribute is not provided, "some screen readers will announce the file name of the image instead" (W3C WAI, decorative images). alt="" tells assistive technology to skip the image entirely, which is right for decoration and wrong for anything else.

WCAG defines pure decoration as "serving only an aesthetic purpose, providing no information, and having no functionality". A practical test follows from that: imagine the image gone. If a sighted visitor would lose no information and no way to act, it is decorative. If they would lose anything, it is not. Typical decorative cases:

• a flourish, divider or background texture;
• an icon sitting next to text that already says the same thing, such as a phone icon beside "Call us";
• a photo whose visible caption, tied to it in code, already carries everything it shows.

Two W3C failure techniques cover the decorative side: F38, not marking decorative images so assistive technology can ignore them, and F39, giving such an image a non-empty alternative such as "spacer". W3C also suggests that where possible, decorative images be supplied as CSS backgrounds, which assistive technology ignores by default. For a borderline image, W3C's alt decision tree walks through the choice question by question.

The dangerous mistake runs the other way. An informative image marked alt="" disappears for screen reader users, and it passes rule-based checkers, because an empty alt is valid markup that says "decorative" whether or not that is true. The same applies to a linked image with empty alt and no other text in the link: the link loses its only name. Rule checkers do catch that one, because the link itself has no name.

Present but false: why accuracy is part of 1.1.1

The criterion does not ask for "an alt attribute". It asks for a text alternative that serves the equivalent purpose. W3C's Understanding 1.1.1 states the intent is "to make information conveyed by non-text content accessible through the use of a text alternative". Alt text that describes a different picture does not serve that purpose; it misinforms the person relying on it. W3C's own failure techniques say as much:

• F30: text alternatives that are not alternatives, such as filenames or placeholder text.
• F20: not updating text alternatives when the non-text content changes. This is the stale alt text left behind when a product photo is swapped and the old description stays.

Wrong alt text is easiest to introduce at scale: catalog imports that copy one description to every variant, templates with a default alt, photos replaced in a CMS that keeps the old text, and AI-generated drafts nobody read. Every one of them produces well-formed markup that a parser passes. Our alt text guide covers writing good alternatives; alt text examples, alt text for product images and how accurate AI alt text is go deeper on each case.

Failing and passing code

Each pair below is a pattern we see repeatedly. The failure technique named is W3C's where one applies.

Missing alt attribute (F65)

Failing, per F65. Some screen readers will read out the file name:

<img src="/img/hero-summer.jpg">

Passing:

<img src="/img/hero-summer.jpg"
  alt="Kayaks on a lake at dawn">

Image button with no alt (F65)

Failing. F65 names <input type="image"> as well as <img>: this button has no name at all:

<input type="image"
  src="go.png">

Passing. The alternative names the action:

<input type="image"
  src="go.png" alt="Search">

Image map area with no alt (F65)

Failing. Each <area> is a link, and this one has no text:

<img src="regions.png"
  alt="Sales regions"
  usemap="#regions">
<map name="regions">
  <area href="/north/"
    coords="0,0,80,60">
</map>

Passing. The area's alt says where the link goes:

<area href="/north/"
  coords="0,0,80,60"
  alt="North region">

Filename or placeholder as alt (F30)

Failing:

<img src="IMG_4021.jpg"
  alt="IMG_4021.jpg">
<img src="logo.svg" alt="logo">

Passing. A logo's alternative is the name it shows, not the word "logo":

<img src="IMG_4021.jpg"
  alt="Tan suede ankle boot">
<img src="logo.svg"
  alt="Acme Outdoor">

Decorative image given a description (F39)

Failing. A screen reader user hears "decorative swirl" between two headings, for nothing:

<img src="divider.svg"
  alt="decorative swirl">

Passing:

<img src="divider.svg" alt="">

Image link with no name

Failing. The image is the only content of the link, and empty alt leaves the link silent or announced by its address:

<a href="/cart/">
  <img src="cart.svg" alt="">
</a>

Passing. A functional image describes the action, not the picture:

<a href="/cart/">
  <img src="cart.svg" alt="Cart">
</a>

Icon button built from inline SVG

Failing. The button has no text and the SVG has no name:

<button type="button">
  <svg viewBox="0 0 24 24">
    <path d="M3 6h18M3 12h18"/>
  </svg>
</button>

Passing. The button carries the name, and the drawing is hidden because the name already says everything:

<button type="button"
  aria-label="Menu">
  <svg viewBox="0 0 24 24"
    aria-hidden="true">
    <path d="M3 6h18M3 12h18"/>
  </svg>
</button>

Informative inline SVG

Failing. A star rating drawn in SVG, with nothing that names it:

<svg viewBox="0 0 120 24">
  <path d="..."/>
</svg>

Passing. Here the drawing is the content, so it gets role="img" and a name of its own:

<svg viewBox="0 0 120 24"
  role="img"
  aria-label="4.5 out of 5 stars">
  <path d="..."/>
</svg>

Image of text

Failing. The banner reads "Sale: 30% off all boots", but the alternative keeps one word of it:

<img src="sale-banner.png"
  alt="Sale">

Passing for 1.1.1. Better still is real text styled with CSS, which 1.4.5 Images of Text prefers at Level AA:

<img src="sale-banner.png"
  alt="Sale: 30% off all boots">

Stale alt after a photo swap (F20)

Failing. The file was replaced with a tan boot; the description still names the old one. Every rule-based checker passes this:

<img src="boot-tan-front.jpg"
  alt="Black leather ankle boot">

Passing:

<img src="boot-tan-front.jpg"
  alt="Tan suede ankle boot">

A chart: short alternative plus the data

Failing. The alternative says what kind of thing it is, and none of what it shows:

<img src="q3-sales.png"
  alt="chart">

Passing. A chart cannot be summarized in a sentence, so the alternative names it and points to the full data, which sits in real text on the page. W3C's complex images tutorial covers other ways to provide the long description:

<img src="q3-sales.png"
  alt="Q3 sales: see table below">
<table>
  <caption>
    Q3 sales by region
  </caption>
  ...
</table>

Information in a CSS background (F3)

Failing, per F3. The word "New" exists only inside the background picture:

<span class="badge-new"></span>

.badge-new {
  background: url(new-badge.png);
}

Passing. The information is real text, and CSS only styles it:

<span class="badge-new">New</span>

How to test WCAG 1.1.1, step by step

Automated checks cover the first steps quickly. The steps that decide most real failures need a person reading alternatives against images.

1. Inventory every non-text item, not only <img>. Run the accessibility bookmarklet or the console snippet below, then look for inline SVG icons, icon fonts, image buttons, canvas, video, audio and CSS backgrounds that carry words.
2. Classify each one as informative, functional (inside a link or button), decorative, complex (a chart or diagram) or one of the exceptions above.
3. Confirm the alternative exists and is wired up. For images, an alt attribute. For links and buttons, an accessible name: the Accessibility pane in your browser's developer tools shows the computed name.
4. Read each alternative against the image. Ask: if the picture failed to load, would this text do the same job? For a functional image, does it name the action ("Search") rather than the drawing ("magnifying glass")?
5. Check the decorative calls. For every alt="", apply the removal test. A meaningful image marked decorative is a failure no rule checker reports.
6. Check images of text. The alternative should contain the same words the image shows.
7. Check complex images have a short alternative and a full description or data table the user can reach.
8. Listen once. Move through the page with a screen reader such as NVDA on Windows or VoiceOver on a Mac, using its images or graphics list where it has one, to hear what is actually announced.
9. Repeat after content changes. Catalog imports, CMS migrations and redesigns are where F20, stale alternatives, comes from.

For step 1, paste this into your browser's developer console on the page you are testing. It lists every <img> with its alt text, and marks those with no alt attribute at all:

// Each img, its alt, its file
const imgs = document.images;
for (const img of imgs) {
  const a =
    img.getAttribute("alt");
  const label = a === null
    ? "NO ALT" : `"${a}"`;
  console.log(label, img.src);
}

It sees only <img> elements, so SVG icons, CSS backgrounds and canvas still need a look of their own. Our guide to testing website accessibility covers the rest of a manual pass.

False positives, false negatives and edge cases

Automated results for 1.1.1 go wrong in both directions. These are the cases we see most often.

What GotAlt checks for 1.1.1, and what it cannot

Each of our tools covers a different slice of the criterion. The table states exactly what each checks, matching the descriptions on each tool's own page and our methodology.

Related criteria

• 1.2.1 to 1.2.5: captions, transcripts and audio description for time-based media.
• 1.4.5 Images of Text (AA): use real text instead of pictures of text where you can.
• 1.4.11 Non-text Contrast (AA): icons and graphics that carry meaning need 3:1 contrast. See also our color contrast guide.
• 2.4.4 Link Purpose and 4.1.2 Name, Role, Value: image links and icon buttons need names.

For every criterion in one place, see WCAG 2.2 criteria explained and the WCAG 2.2 checklist. Platform notes for alt text fields are in our guides for Shopify, WordPress, Wix, Squarespace and Webflow.