What 1.4.3 requires
The visual presentation of text and images of text must have a contrast ratio of at least 4.5:1. Large-scale text (at least 18 point, or 14 point bold, roughly 24px or 18.5px bold in CSS) needs at least 3:1. This is a plain-language summary. The normative text, including every exception, is in the W3C Recommendation, with the W3C's explanation in Understanding 1.4.3 (opens in a new tab) [1][2].
Exceptions and scope:
- Incidental text: inactive (disabled) controls, pure decoration, text that isn't visible, and text that's part of a picture with other significant visual content.
- Logotypes: text in a logo or brand name has no contrast requirement.
Why it matters
Low-contrast text is hard to read for people with low vision and color-vision differences, and for everyone on a phone in sunlight. It was the most common failure in WebAIM's 2026 analysis of the top million home pages: low-contrast text was detected on 83.9% of them [4].
Common failures
Light gray body text
Fashionable pale gray on white often falls below 4.5:1.
/* Fails */
color: #9a9a9a; /* on #ffffff ≈ 2.8:1 */
/* Better */
color: #595959; /* on #ffffff ≈ 7:1 */Placeholder text used as instructions
Browser-default placeholder colors are often low contrast, and they carry the format hint.
<!-- Fails -->
<input placeholder="DD/MM/YYYY">
<!-- Better -->
<label>Date of birth <span class="hint">DD/MM/YYYY</span></label>Text over images or gradients
Contrast varies across the image, and part of the text drops below the threshold.
/* Fails */
.hero h1 { color:#fff } /* over a bright photo */
/* Better */
.hero h1 { color:#fff; background: rgb(0 0 0 / .6) }States that lose contrast
Hover, focus, error or 'selected' styles that switch to a pale color.
/* Fails */
.tab[aria-selected=true]{color:#a3c4ff}
/* Better */
pick state colors that still meet 4.5:1Can automated testing check 1.4.3?
Mostly yes for plain text on solid backgrounds; partly for text over images or gradients: Accessible's scans settle clear passes and clear failures, and mixed backgrounds still need a person. No for states the tool didn't render.
| axe-core 4.13.0 rule | What it checks |
|---|---|
color-contrast | foreground/background contrast meets the WCAG 2 AA thresholds (axe-core marks cases it can't determine, such as images behind text, as "needs review") |
What automation can't decide: Mixed backgrounds behind text, text inside images, and states that only appear after interaction (hover, focus, error, dark mode, a third-party widget that loads later), unless the tool renders that state.
A clean automated result is never proof that 1.4.3 is met. See why sites pass axe-core but fail real screen reader users.
How to test it by hand
- Sample text and background colors with a contrast checker (browser dev tools show the ratio in the color picker).
- Check every text style: body, small print, links, buttons, placeholders, captions, error messages.
- Hover and focus interactive elements and re-check the state colors.
- Check text on images and gradients at the lightest point behind the text.
- Repeat in dark mode, if the site supports it.
New to screen readers? Start with how to test a website with a screen reader and how to test keyboard-only navigation.
How Accessible helps (and where it stops)
Scanning runs axe-core's color-contrast rule on every URL on a paid plan, in a real browser. Real-user monitoring runs axe-core inside sampled real visitors' sessions, so contrast failures in content only real visitors see (logged-in pages, personalized content, third-party widgets, A/B variants) are checked too, and ranked by how many sessions met them.
Where it stops: Journeys don't judge contrast. Where axe-core can't compute contrast from CSS, such as text over an image or a gradient, scans photograph the background behind the text and settle the case only when every background pixel clearly passes or clearly fails. Mixed backgrounds, text shadows, video and animation stay "needs review" and need a person with a contrast checker. No automated tool, ours included, can certify that a criterion is met.
Related criteria
Sources
- Understanding Success Criterion 1.4.3: Contrast (Minimum) (opens in a new tab). W3C Web Accessibility Initiative. Accessed October 18, 2026.
- Web Content Accessibility Guidelines (WCAG) 2.2, Success Criterion 1.4.3 (opens in a new tab). W3C Recommendation. Accessed October 18, 2026.
- axe-core rule descriptions (opens in a new tab). Deque Systems, axe-core 4.13.0. Accessed October 18, 2026.
- The WebAIM Million: The 2026 report on the accessibility of the top 1,000,000 home pages (opens in a new tab). WebAIM, 2026. WAVE-detected errors on home pages only. Accessed October 18, 2026.
Meeting a success criterion is not the same as legal compliance, which depends on the rules that apply to you. No automated tool can certify conformance.