CSS Background Images Are Hiding Content From Real People

CSS background images were designed for decoration. Using them to convey meaning isn't a gray area or a technicality — it's a decision that erases information for people who need it most.

This is what WCAG 2.2 Failure F3 (opens in new window) documents: a pattern that strips content from the accessibility layer entirely. And once again, it's one of those failures that's completely invisible to the developer who wrote it — while being completely disabling for the screen reader user who encounters it.

The Failure

The background-image CSS property has no mechanism for associating a text alternative. None. That's not a limitation waiting for a fix — it's how the property was designed, because it was built for purely decorative use.

When developers use it to present meaningful content, that content simply does not exist for assistive technology. WCAG Success Criterion 1.1.1 Non-text Content (opens in new window) requires that all non-text content conveying information have a text alternative. CSS background images cannot satisfy that requirement by any mechanism available in the spec.

The W3C's examples in F3 are instructive because they're so mundane — and so common.

The first is a financial services page where a 180×200 pixel image containing the text "19.3% APR Typical Variable" is loaded as a background image:

pbestinterest {
  padding-left: ;
  background: transparent url(/images/TopRate.png) no-repeat top left;
}

<p id="bestinterest">Where else would you find a better interest rate?</p>

A screen reader user hears: "Where else would you find a better interest rate?" The actual rate — the information a person would need to make a financial decision — is gone.

The second example involves a book inventory system using CSS class-based background icons to indicate availability status:

ulbooklist li.new { background: transparent url(new.png) no-repeat top left; }
ulbooklist li.limited { background: transparent url(limited.png) no-repeat top left; }
ulbooklist li.instock { background: transparent url(instock.png) no-repeat top left; }
ulbooklist li.outstock { background: transparent url(outstock.png) no-repeat top left; }

<ul id="booklist">
  <li class="new">Some book</li>
  <li class="instock">Some other book</li>
  <li class="limited">A book we desperately want to get rid of</li>
</ul>

A screen reader user gets a list of book titles with no availability information at all. The icons communicating "new," "limited," "in stock," or "out of stock" are invisible to them.

Why This Matters

Think about who this affects in concrete terms.

A blind user navigating the financial services page can't access the APR information that's legally required to be disclosed. A screen reader user shopping for books can't tell whether an item is available before attempting to order it. A user relying on high contrast mode — which may override background images entirely — loses the same information. The W3C explicitly flags this: people who use alternate backgrounds for legibility and users of high contrast mode in some operating systems will lose background image content with no fallback.

This isn't just a screen reader problem. It's a problem for anyone whose visual environment differs from the developer's assumptions.

The pattern also reveals a deeper issue in how organizations think about accessibility testing. Our research on automated testing methodology found that automated tools catch at most 37% of accessibility barriers. CSS background image failures can sometimes be flagged by automated tools — but only when the tool knows to look for meaningful content in a background property, which requires contextual judgment that automation often lacks. A test suite that passes this pattern isn't giving you a clean bill of health.

The Fix

The solution isn't complicated. Replace the CSS background image with an HTML <img> element carrying a meaningful alt attribute. Move the decorative positioning to CSS where it belongs, and put the content in the markup where assistive technology can reach it.

For the financial services example:

<!-- Broken: information trapped in CSS -->
<p id="bestinterest">Where else would you find a better interest rate?</p>
<!-- background-image in CSS contains "19.3% APR Typical Variable" -->
<!-- Fixed: information in the HTML layer -->
<p id="bestinterest">
  <img src="/images/TopRate.png" alt="19.3% APR Typical Variable" />
  Where else would you find a better interest rate?
</p>

For the book availability icons:

<!-- Broken: status communicated only through CSS class + background image -->
<li class="new">Some book</li>
<!-- Fixed: status in accessible markup -->
<li>
  <img src="new.png" alt="New" />
  Some book
</li>

If an image is genuinely decorative, background-image is appropriate — or use <img alt=""> with an empty alt attribute to signal to assistive technology that the image carries no information. The distinction matters: decorative images should be hidden from screen readers, not informational ones.

Applying This

This failure pattern tends to enter codebases through a few predictable routes: designers who work in visual tools and hand off CSS without accessibility review, developers who reach for background-image because it's convenient for layout, and CMS templates that generate background images dynamically via inline styles or JavaScript.

That third path — dynamic generation via client scripts — is explicitly called out in F3 and worth flagging in code review. A background image set via JavaScript carries exactly the same accessibility problem as one set in a stylesheet.

In code review: Flag any background-image usage where the image appears to contain text or symbols that communicate status, action, or content. Ask: does this image carry meaning a user needs? If yes, it belongs in HTML.

In automated testing: Tools like axe and Lighthouse have limited ability to evaluate CSS background images for meaningful content. This is a category where manual review fills the gap that automation leaves open. A human reviewer who understands the page's purpose can identify when a background image is doing semantic work.

In design: Establish a team norm that icons communicating status, availability, or action states are always implemented as <img> elements with alt text — not as CSS backgrounds. This is a design system decision that prevents the problem before it reaches production.

Language access dimension: Organizations serving multilingual communities face a compounded problem here. If the alt text for a meaningful background image is eventually added but only in English, screen reader users with limited English proficiency are still excluded. Tools like idioma.chat (opens in new window) address this by translating not just visible text but the full accessibility layer — ARIA labels, alt text, form validation messages, and dynamically loaded content — so that multilingual users who rely on assistive technology aren't left behind by a half-fix. Accessibility without language access is incomplete accessibility.

CORS Perspective

From a community lens, F3 failures concentrate harm in exactly the places where the stakes are highest — financial disclosures, product availability, status indicators. These aren't edge cases in obscure interfaces; they're the kinds of decisions that determine whether a blind user can comparison-shop, understand a loan offer, or know whether a product is in stock before attempting a purchase. The operational fix is genuinely low-cost once a team understands the pattern, which makes the compliance framework gap here particularly frustrating: organizations that have invested in accessibility programs still ship this failure because it doesn't appear in automated test results and no one flagged it in design review. The strategic argument for fixing it is straightforward — it requires a code change, not a process overhaul — but getting there requires teams to understand why CSS background images are architecturally incapable of carrying accessible content, not just that they're "bad practice."