F83: When Background Images Erase Your Text
Keisha · AI Research Engine
Analytical lens: Community Input
Community engagement, healthcare, grassroots
AI-assisted · Source-linked · Editorially reviewed · Methodology
Trust note
This article was drafted with AI assistance, reviewed against accessibility.chat editorial standards, and should be treated as research and education rather than legal advice. We prioritize primary sources and correct material errors.

WCAG 2.0 turned 16 years old this month. Most enterprise websites still can't pass it. And one of the most visually obvious failures — text rendered unreadable by a competing background image — remains stubbornly common across healthcare portals, government sites, and retail experiences that serve millions of people daily.
WCAG Failure F83 (opens in new window) documents exactly this pattern. It's not a subtle edge case. It's a failure mode that erases content for people with low vision, and it applies to every technology stack without exception.
The Failure
F83 describes what happens when a background image interferes with foreground text to the point that the text becomes unreadable. The W3C's official description is precise: the failure occurs when "features of the background image can be confused with the text making it difficult to accurately read the text."
Two concrete examples appear in the source document. In the first, black text overlays an image containing black lines — the lines cross behind letterforms, turning F's into E's and degrading word recognition entirely. In the second, black text crosses dark gray areas in a background image, producing localized contrast ratios so poor the text simply disappears into the image.
This failure maps to two WCAG 2.2 success criteria (opens in new window):
| Success Criterion | Level | Requirement | Minimum Ratio (Normal Text) | Minimum Ratio (Large Text) |
|---|---|---|---|---|
| 1.4.3 Contrast (Minimum) (opens in new window) | AA | Text and images of text meet contrast threshold | 4.5:1 | 3:1 |
| 1.4.6 Contrast (Enhanced) (opens in new window) | AAA | Stricter threshold for text readability | 7:1 | 4.5:1 |
For images specifically, the W3C is explicit: "there would need to be sufficient contrast between the text and those parts of the image that are most like the text and behind the text." Not the average contrast across the image. Not the lightest area. The worst-case region where text and background compete most directly.
The failure applies to any technology — HTML/CSS, PDF, native mobile, video overlays. No platform is exempt.
Why This Matters
Approximately 246 million people globally live with moderate to severe vision impairment (opens in new window). Low contrast text on a flat background is already a problem for this population. Low contrast text over a visually complex background image is compounding that problem — the image introduces noise that a person with low vision cannot mentally filter out the way a sighted person with full acuity might.
Consider what actually happens during the reading experience. A person with low vision using magnification software zooms into a region of text. The background image also magnifies. What was a subtle texture at normal zoom becomes a field of competing shapes at 4x magnification. The letterforms and the background patterns occupy the same visual frequency. Reading becomes guesswork.
For screen reader users, this failure is invisible — but that doesn't mean it's harmless. Many people who use screen readers also have partial vision. They use both the visual display and audio output together. A failure that makes text visually inaccessible affects a population that doesn't map neatly onto any single assistive technology category.
Cognitive load matters here too. When contrast is degraded, reading requires more effort. For people with cognitive disabilities, that additional processing burden isn't a minor inconvenience — it can make the difference between completing a task and abandoning it entirely.
This is a human dignity issue before it's a compliance issue. When a healthcare site renders its appointment instructions unreadable over a decorative banner image, that's not a design oversight. That's a barrier to care.
The Fix
The failure pattern looks like this — text placed over an image with insufficient contrast control:
<!-- Failure pattern: no contrast control over background image --><div style="background-image: url('hero-photo.jpg'); color: #000000;"> <p>Schedule your appointment today</p></div>The background image may have light areas where the text reads fine and dark areas where it disappears. The contrast ratio isn't uniform — and the worst-case region is what determines compliance.
Correct patterns include several options depending on design constraints:
<!-- Fix 1: Semi-transparent overlay to control contrast --><div style="position: relative;"> <div style= background-image: url('hero-photo.jpg'); background-size: cover; position: absolute; inset: 0; ></div> <div style= position: relative; background-color: rgba(0, 0, 0, 0.75); color: #ffffff; padding: 1.5rem; > <p>Schedule your appointment today</p> </div></div><!-- Fix 2: Text shadow to separate text from variable background --><p style= color: #ffffff; text-shadow: 0 0 8px rgba(0,0,0,0.9), 0 0 4px rgba(0,0,0,0.9);>Schedule your appointment today</p><!-- Fix 3: Solid background behind text block --><div style= background-image: url('hero-photo.jpg'); background-size: cover;> <p style= background-color: #1a1a1a; color: #ffffff; display: inline-block; padding: 0.5rem 1rem; >Schedule your appointment today</p></div>Fix 1 is the most robust — a semi-transparent overlay creates a consistent contrast surface regardless of what the image contains underneath. Fix 3 is the safest for AAA compliance because it uses a solid background. Fix 2 (text shadow) requires careful testing because shadow diffusion varies by rendering engine.
The key principle: contrast must be evaluated at the worst-case intersection of text and image, not at an average or ideal position.
Applying This
This is a failure that automated tools handle inconsistently. Standard contrast checkers measure text against a flat background color. When the background is an image, most automated tools either skip the check or sample a single pixel — which may land on the lightest region and return a false pass.
Our research paper Beyond Detection: Why Context Separates Automated Testing from Manual Audits documents this limitation directly: automated tools detect at most 37% of real accessibility failures. F83 failures are a textbook example of what falls into that 63% gap.
Practical steps for development teams:
- In design review: Flag any composition where text appears over a photographic or illustrated background. Require designers to demonstrate contrast compliance at the worst-case image region, not just the intended placement.
- In code review: Any
background-imageCSS combined with foreground text should trigger a manual contrast check. This is a two-line pattern to grep for. - In QA: Test at multiple viewport sizes. Background images scale and shift. A composition that passes at desktop may fail at mobile because the image crops to a darker region.
- For existing sites: A targeted audit searching for
background-imagein stylesheets combined with any text overlay is a high-yield, low-effort sweep. This is the kind of specific inspection that manual audits catch that automated scans miss entirely.
Language access intersects here in a way practitioners rarely consider. When a page is translated — say, from English to Vietnamese — the translated text may be longer, causing it to reflow into a darker region of the background image that the original English text never touched. A contrast check that passed for English may fail for the translated version. Tools like idioma.chat (opens in new window) translate the full accessibility layer — ARIA labels, alt text, form validation messages, and dynamically loaded content — but that translation infrastructure only delivers equal access if the visual contrast holds across all language versions. Accessibility and language access are not separate audits. They're the same audit, run across every language the site serves.
CORS Perspective
From a community impact lens, F83 failures concentrate harm in the populations least able to advocate for remediation — people with low vision who may not identify the visual design as the source of their difficulty, and multilingual users with disabilities navigating sites that were never tested in their language. Operationally, this is a "chop list" fix: a targeted grep for background-image plus text overlay, combined with a manual contrast check at worst-case image regions, resolves the majority of F83 exposure without requiring a full site audit. The risk priority is medium-to-high — 1.4.3 Contrast (Minimum) (opens in new window) is a Level AA requirement, meaning it's the baseline standard for most legal compliance frameworks, including Section 508 (opens in new window) and the DOJ's digital accessibility guidance under Title II (opens in new window). Strategically, design teams respond better to this fix when it's framed as protecting brand legibility — because a background image that erases your text doesn't just fail disabled users. It fails everyone reading in bright sunlight on a mobile screen.
About the Keisha lens
A community-impact lens. Frames findings around who is excluded and what a barrier means in practice, with emphasis on healthcare and grassroots access.
Keisha is an AI analyst lens, not a human staff member. It helps frame this article through a consistent accessibility perspective.
Specialization: Community engagement, healthcare, grassroots
View all articles using this lens →Primary source reviewed: https://www.w3.org/WAI/WCAG22/Techniques/failures/F83 (opens in new window)
Transparency Disclosure
This article was drafted with AI assistance and reviewed against our editorial methodology. We disclose that process so readers can judge the work clearly.