Images of Text in E-Commerce: What WCAG SC 1.4.5 Requires (and When a Sale Banner Is Fine)

Quick answer: WCAG SC 1.4.5 Images of Text (Level AA) requires that when a site’s technology can already achieve a visual effect with real text and CSS, it uses real text instead of a flattened image of that text — a common e-commerce failure being a “20% OFF SITEWIDE” sale banner, a coupon-code graphic, or a price-drop badge shipped as one JPEG or PNG with the words baked in. This is different from alt text: even a perfectly written alt="20% off orders over $75" doesn’t fix a 1.4.5 problem, because the criterion is about letting a low-vision user change the text’s size, color, font, or spacing via their browser — something no amount of good alt text can do for a picture. There are two narrow exceptions (a logo is one of them), and the fix in most cases is just: build the banner with HTML and CSS instead of an image editor.

This article covers technical accessibility practice, not legal advice — it explains what WCAG 2.1 AA requires for this pattern and how to meet it, not whether a specific implementation carries legal risk.

What the success criterion actually requires

The Understanding doc states the criterion plainly: “If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text except for the following:

• Customizable: The image of text can be visually customized to the user’s requirements;
• Essential: A particular presentation of text is essential to the information being conveyed.“

A note attached to the Essential exception matters a lot for e-commerce specifically: “Logotypes (text that is part of a logo or brand name) are considered essential.” Your store’s wordmark logo is exempt outright. A sale banner’s headline text is not a logo, and doesn’t automatically inherit that exemption just because it sits inside a nicely designed graphic.

The Intent section explains why the criterion exists at all: “to encourage authors … to enable people who require a particular visual presentation of text to be able to adjust the text presentation as needed. This includes people who require the text in a particular font size, foreground and background color, font family, line spacing or alignment. If authors can use text to achieve the same visual effect, they should present the information as text rather than using an image.” A low-vision shopper who has their browser set to a large, high-contrast, dyslexia- friendly font gets that treatment automatically for real text on the page — and gets nothing for text baked into a raster image, no matter how good the surrounding page’s accessibility is otherwise.

The doc also narrows what actually counts as “essential,” beyond logos: type samples, situations where a specific font isn’t widely deployed or the site doesn’t have redistribution rights, and cases where anti-aliasing needs to be guaranteed across user agents. It’s also explicit about what doesn’t count as an image of text at all: “This does not include text that is part of a picture that contains significant other visual content. Examples of such pictures include graphs, screenshots, and diagrams.” A screenshot of an actual customer review or social-media post, with the platform’s own UI chrome, avatar, and layout intact, is a picture with significant other visual content — SC 1.4.5 doesn’t apply to it at all (though SC 1.1.1’s alt-text rules still do). A cropped screenshot that’s really just isolated text on a plain background is a different case, and 1.4.5 applies to that the same as any other flattened text graphic.

Where this shows up on e-commerce sites

• Sale and promo banners. The most common case: a marketing team designs a “FLASH SALE — 30% OFF” graphic in a design tool and exports it as a single image for the homepage hero or a category-page header. The text can’t be resized, recolored, or restyled by a visitor’s browser settings — it’s pixels, not characters.
• Coupon-code graphics. A styled “Use code SAVE20 at checkout” image is exactly the kind of content a shopper might need to zoom in on or view in a higher-contrast mode, and exactly the kind of content that’s trivial to build as real text with CSS instead.
• Price-drop and “was/now” badges. Small graphic badges showing a struck-through original price and a highlighted new price are usually simple enough to build with real text, a <del> element, and CSS — no image required, and no exception applies just because it’s small.
• Brand logotype — the legitimate exception. A wordmark in the header or on packaging photos is squarely covered by the Essential exception’s own named example. This article isn’t arguing for rebuilding logos as live text; it’s about the promotional and informational graphics around them.

The fix

For the overwhelming majority of e-commerce cases, Technique C22 — using CSS to control the visual presentation of text — is the whole fix: build the banner as real HTML text and use CSS for the font, color, size, and layout that used to live inside the image file.

<!-- Fails 1.4.5 — the discount, code, and end date are all pixels inside one flattened image -->
<img src="/promo/flash-sale-30-off.jpg" alt="Flash sale, 30% off, code SAVE30, ends Sunday" />

<!-- Passes — real text, styled with CSS; a user's font/contrast/zoom settings apply to it -->
<div class="promo-banner">
  <p class="promo-banner__headline">Flash Sale — 30% Off</p>
  <p class="promo-banner__code">Use code <strong>SAVE30</strong> at checkout — ends Sunday</p>
</div>

.promo-banner {
  background: var(--brand-mint);
  padding: 1.5rem 2rem;
  text-align: center;
}
.promo-banner__headline {
  font-size: clamp(1.5rem, 4vw, 2.25rem);
  font-weight: 700;
}

A decorative background image, gradient, or illustration behind the text is fine — the criterion is about the text itself, not about whether any imagery is present on the banner at all.

Where a design genuinely needs to keep a specific raster treatment — a hand-lettered or illustrated wordmark used as a one-off seasonal graphic, for example — Technique C30 covers building it as real HTML text with one stylesheet that renders the plain version and a second that swaps in the custom graphic treatment, with a user-facing control to choose between them — more work than C22, and the exception-handling path rather than the default.

The stricter AAA-level sibling

The Understanding doc draws a direct line to a related, stricter criterion: “This is in contrast to 1.4.9 Images of Text (No Exception), which applies to all images of text, regardless of whether or not they are used in addition to text.” SC 1.4.9 is Level AAA — optional under the WCAG 2.1 AA benchmark this site’s audits are built around, and even a logo can’t lean on the Essential exception under 1.4.9. Worth knowing it exists; most e-commerce sites won’t need it.

Can an automated scanner catch this?

Not directly. A direct search of axe-core’s own rule descriptions for wcag145 returns zero matches. Axe’s image-alt rule checks whether an <img> has any accessible name — it has no way to evaluate whether that image’s content should have been real text in the first place, because that’s a design and implementation judgment, not a presence-or- absence markup check. A sale banner with a well-written alt attribute passes every automated image-related check axe runs, while still failing SC 1.4.5 outright. This is exactly the kind of gap a manual review is built to catch: someone actually looking at the page and asking “could this have been text?”

FAQ

If I already write good alt text for my sale banners, do I still need to fix this? Yes. Alt text (SC 1.1.1) makes an image’s content available to screen reader users. SC 1.4.5 is a separate requirement aimed at a different group — people who can see the page but need to change how text is presented (larger size, different font, different colors) using their browser’s own settings. Good alt text and real, CSS-styled text solve two different problems; neither one covers the other.

Does this mean I can never use a promotional graphic that includes any text? No. A background illustration, icon, or decorative pattern behind real HTML text is fine — the criterion only concerns text that’s flattened into the image itself, not text overlaid on or near an image via normal HTML/CSS layout.

What about a screenshot of a glowing customer review from Instagram? If it’s a genuine screenshot with the platform’s own interface, avatar, and layout — “significant other visual content” in the Understanding doc’s own words — SC 1.4.5 doesn’t apply to it at all; it’s a picture, not an image of text. If it’s been cropped down to just the review’s text on a plain background, it’s functionally an image of text like any other and the same fix applies: reproduce the quote as real HTML text.

Get a human-reviewed audit, not just a scan

Whether a banner “should” be real text or an image is a judgment call no automated scanner makes — it takes someone looking at the actual page. Quietramp’s audits pair an automated scan with a manual review that catches exactly this kind of gap, delivered as a prioritized, developer-actionable PDF report. See a real sample report or check pricing — $890 one-time, $99/month for ongoing re-checks after fixes ship.

---

This article is general accessibility information, not legal advice. Meeting WCAG 2.1 AA does not resolve ADA or any other legal compliance question, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.

This article was drafted with AI assistance and reviewed by a person for accuracy before publication.