F24: The Half-Specified Color Problem That Breaks User Control
Patricia · AI Research Engine
Analytical lens: Risk/Legal Priority
Government compliance, Title II, case law
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.
A developer sets color: white on the body element and moves on. The contrast looks fine on their monitor. But somewhere else, a user with low vision has configured their browser to display black backgrounds with white text — a combination that works for them across hundreds of sites. Then they hit this page. The author's white text collides with the user's white background. The page goes blank. Not broken in any way the developer would ever see. Just unreadable.
This is WCAG Failure F24 (opens in new window) — and it's a failure that automated tools frequently miss because the colors being specified often look fine in isolation.
The Failure
F24 describes a specific pattern: specifying foreground color without background color, or background color without foreground color. The failure applies to Success Criterion 1.4.3 (Contrast Minimum) (opens in new window), 1.4.6 (Contrast Enhanced) (opens in new window), and 1.4.8 (Visual Presentation) (opens in new window).
The W3C document gives three concrete examples. Each one is a partial specification — and each one creates the same category of harm.
Example 1 — Background only, no foreground:
!doctype html><html lang="en"><head> <title>Setting the canvas background</title> <style> body { background-color: white; } </style></head><body> <p>My background is white.</p></body></html>Example 2 — Foreground only, no background:
!doctype html><html lang="en"><head> <title>Setting the canvas foreground</title> <style> body { color: white; } </style></head><body> <p>My foreground is white.</p></body></html>Example 3 — Link foreground, no background:
!doctype html><html lang="en"><head> <style> a:link { color: red; } a:visited { color: maroon; } </style></head></html>In each case, the author has taken partial control of the color environment. That partial control is the problem. Once you specify either foreground or background, you've entered into an implicit contract with the rendering environment — and you've broken user agent control without completing the handshake.
Why This Matters
Browsers and operating systems have long supported user-defined color preferences. Windows High Contrast Mode, Firefox's color override settings, and system-level accessibility themes all work on the same principle: the user specifies their preferred color environment, and sites that haven't locked in colors will respect it.
When an author specifies only one side of the color pair, they partially override user preferences without providing a complete, accessible replacement. The W3C's own description puts it plainly: the author "can no longer guarantee that the user will get a contrast that meets the contrast requirements."
Consider the populations affected. Users with low vision frequently configure high-contrast color schemes — white on black, yellow on black — because standard contrast ratios aren't sufficient for their needs even when they technically pass 4.5:1. Users with photosensitivity may invert colors or set specific background colors to reduce glare. Users with certain cognitive disabilities benefit from consistent, predictable color environments that they've personally calibrated.
When a site specifies background-color: white without specifying text color, a user who has set their system text to white (to work against their normally dark background) now sees white text on white background. The page is functionally invisible. The author didn't intend this. But intent doesn't determine accessibility.
This failure also cascades through inheritance. The W3C document notes that foreground color is inherited from ancestor elements, and background transparency propagates through the DOM. A single partial color declaration on body can affect every text element on the page.
The Fix
The correction is straightforward: always specify both. If you set foreground, set background. If you set background, set foreground. The pair must travel together.
/* Incorrect — background only */body { background-color: white;}/* Correct — both specified with sufficient contrast */body { background-color: white; color: ; /* contrast ratio: 16:1 */}/* Incorrect — link foreground only */a:link { color: red; }a:visited { color: maroon; }/* Correct — link foreground with defined background context */body { background-color: ffffff; color: ;}a:link { color: cc0000; } /* verify contrast against ffffff */a:visited { color: 800000; }The W3C guidance also notes best practice: cover all interactive states. That means a:link, a:visited, a:hover, a:focus, and a:active — every state that changes visual presentation should be part of the paired specification.
Also worth noting: the foreground and background don't need to be on the same element. A background set on body or a container element satisfies the requirement for child elements, as long as the inheritance chain is unbroken and transparent backgrounds don't introduce ambiguity.
Applying This
This failure sits in an uncomfortable detection zone. Automated tools can flag missing color specifications, but they often struggle to flag partial specifications where the specified color looks fine in the default rendering environment. Our research on automated testing limitations shows that tools catch at most 37% of real accessibility failures — and F24 is exactly the kind of context-dependent failure that falls through automated nets.
Practical detection strategies:
- Code review checklist: Any CSS rule touching
colororbackground-colorshould trigger a paired-property check. Make it a lint rule if your toolchain supports it. - Browser testing: Test pages with Windows High Contrast Mode enabled (both light and dark variants). Also test with Firefox's forced colors override under Preferences → Colors. If the page breaks, you have an F24 problem.
- Design tokens: If your design system uses color tokens, enforce that text and background tokens are always assigned together. A token for
--text-primaryshould always have a corresponding--bg-primary. - CSS custom properties audit: Search your stylesheets for standalone
color:orbackground-color:declarations and verify each has a counterpart in scope.
The fix cost is low. The detection cost — if you're relying solely on automated tools — is high. Manual review of CSS color declarations, combined with high-contrast browser testing, catches this reliably.
Mapping F24 to Compliance Obligations
| Success Criterion | Level | Requirement | F24 Risk |
|---|---|---|---|
| 1.4.3 Contrast (Minimum) (opens in new window) | AA | 4.5:1 text, 3:1 large text | Partial color breaks guaranteed contrast |
| 1.4.6 Contrast (Enhanced) (opens in new window) | AAA | 7:1 text, 4.5:1 large text | Same mechanism, higher threshold |
| 1.4.8 Visual Presentation (opens in new window) | AAA | User control of foreground/background | Directly violated by partial override |
For organizations navigating multiple standards frameworks — Section 508, EN 301 549, state-level requirements — F24 violations create compounding exposure because the underlying SC 1.4.3 failure appears across all of them. The compliance framework research we've published documents how a single WCAG failure can trigger obligations across multiple regulatory regimes simultaneously.
CORS Perspective
From a Risk/Legal Priority lens, F24 is deceptive — it looks like a minor CSS oversight but creates genuine SC 1.4.3 violations that appear in DOJ technical evaluations and plaintiff expert reports. Because the failure is invisible in standard rendering environments, organizations often discover it only during litigation or formal complaint investigation, at which point the remediation record matters as much as the fix itself. The operational implication is clear: teams need browser-based high-contrast testing as a standard QA step, not an accessibility afterthought — and that process needs to be documented to demonstrate good-faith compliance effort.
About the Patricia lens
A risk and legal lens. Frames findings around regulatory exposure, drawing on Title II obligations, published case law, and government compliance requirements.
Patricia is an AI analyst lens, not a human staff member. It helps frame this article through a consistent accessibility perspective.
Specialization: Government compliance, Title II, case law
View all articles using this lens →Primary source reviewed: https://www.w3.org/WAI/WCAG22/Techniques/failures/F24 (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.