AccessGuardby VASTROX

Color Contrast Checker: Measure WCAG Contrast Ratios and Fix Failures

Color contrast is one of the most common and most fixable accessibility problems on the web. This guide explains the WCAG contrast ratios, how contrast is actually measured, why text and UI elements fail, and how to correct them with real CSS.

The WCAG contrast ratios you need to hit

WCAG defines contrast as a ratio between the relative luminance of two colors, written from 1:1 (no contrast, identical colors) up to 21:1 (pure black on pure white). The higher the ratio, the easier text and interface elements are to perceive, especially for people with low vision, color vision deficiency, or anyone using a screen in bright sunlight.

At WCAG 2.x Level AA, three thresholds cover almost everything you build. Normal body text needs at least 4.5:1 against its background (Success Criterion 1.4.3, Contrast Minimum). Large text needs at least 3:1, where large text means 24px or larger, or 18.66px or larger when bold (roughly 18pt, and 14pt bold). User interface components and meaningful graphics, such as input borders, focus indicators, icons, and chart segments, need at least 3:1 against adjacent colors (Success Criterion 1.4.11, Non-text Contrast).

If you are targeting the stricter Level AAA, the bar rises to 7:1 for normal text and 4.5:1 for large text (Success Criterion 1.4.6). Most teams standardize on AA because it is the level referenced by procurement requirements, the EN 301 549 standard, and readiness signals for the European Accessibility Act.

  • Normal text: at least 4.5:1 (WCAG AA, SC 1.4.3)
  • Large text (24px, or 18.66px bold): at least 3:1
  • UI components and graphics: at least 3:1 (SC 1.4.11)
  • Normal text at AAA: at least 7:1 (SC 1.4.6)
  • Logos and purely decorative elements: no contrast requirement

How contrast ratio is actually measured

A contrast checker does not compare colors by eye or by hue. It converts each color to a relative luminance value, a perceptual measure of how much light the color emits, then compares the two. Getting this right matters because a bright yellow and a bright green can look very different yet have almost identical luminance, which produces a failing ratio even though the colors clearly differ.

The calculation has two steps. First, each sRGB channel (red, green, blue) is normalized to a 0 to 1 range and linearized: if the channel value is at or below 0.04045 it is divided by 12.92, otherwise it is transformed with ((value + 0.055) / 1.055) raised to the power 2.4. Relative luminance L is then 0.2126 times red, plus 0.7152 times green, plus 0.0722 times blue. Green is weighted most heavily because the human eye is most sensitive to it.

With the luminance of both colors known, the contrast ratio is (L1 + 0.05) divided by (L2 + 0.05), where L1 is the lighter color and L2 is the darker one. The 0.05 term models ambient screen glare. This is the exact formula behind every compliant checker, including the AccessGuard scanner, so results are consistent no matter which tool you validate with.

Common contrast failures and why they happen

Most contrast failures are not exotic. They come from a small set of habits that look fine on a designer's calibrated monitor but fall short of the ratio. The most frequent is light gray text on white, such as #999999 on #FFFFFF, which measures about 2.85:1 and fails normal text. Placeholder text is a repeat offender because browser defaults are intentionally faint.

The second big category is text over images or gradients, where the background color varies pixel by pixel and a ratio that passes over the dark part of a photo fails over the bright part. Brand color buttons are another trap: a mid-tone brand blue or green with white label text often lands between 3:1 and 4.5:1, passing for large text but failing normal text. Finally, WCAG 2.1 introduced non-text contrast, so thin 1px input borders, low-contrast focus rings, and pale icons that were invisible before are now measurable failures.

Hover, focus, disabled, and error states are easy to miss because teams check the default state only. A link that passes at rest can fail on hover, and a focus outline that is the same hue as the background provides no visible indicator at all. Disabled controls are exempt from the contrast requirement, but anything a user can still read or act on is not.

Fixing contrast with CSS

The fastest fix is usually to darken the foreground rather than change the hue, which preserves your brand feel. Swapping #999999 for #595959 on white moves a failing 2.85:1 up to about 7:1, clearing AA and AAA for body text. When you cannot move the text color, darken or lighten the background instead, or add a solid or semi-opaque overlay behind text set over imagery.

For text over photos, a translucent scrim is reliable because it forces a predictable background luminance regardless of the image. For UI contrast, thicken or darken borders and give focus states a genuinely visible, high-contrast outline rather than a subtle color shift. Never rely on color alone to signal state, since that fails color-blind users and separate WCAG criteria.

Example fixes:

/* Body text: was #999 on #fff (2.85:1, fails) */ .body-text { color: #595959; } /* ~7:1 on #fff, passes AA + AAA */

/* Text over an image: force a readable background */ .hero-caption { color: #fff; background: rgba(0, 0, 0, 0.6); /* scrim guarantees the ratio */ padding: 0.5rem 0.75rem; }

/* Visible focus indicator (SC 1.4.11, 3:1 minimum) */ .btn:focus-visible { outline: 3px solid #1a56db; outline-offset: 2px; }

/* Input border that meets non-text contrast */ .form-input { border: 1px solid #6b7280; } /* ~3.6:1 on #fff */

  • Darken foreground text before changing its hue to keep brand identity
  • Add a semi-opaque scrim behind text placed over images or video
  • Use focus-visible outlines of 3px or more at 3:1 or better
  • Give inputs, borders, and icons a real 3:1 ratio against their surroundings
  • Never signal state with color alone; pair it with text, icons, or underlines

Scan your whole site, not just one color pair

A single-pair contrast tool answers one question at a time. Real sites have hundreds of color combinations spread across components, states, and content authored by different people over time. Checking them by hand is slow and misses the states that only appear on interaction. Automated scanning is how you find every failure and keep it fixed as the site changes.

The free VASTROX AccessGuard scanner crawls your pages, computes the exact WCAG luminance ratios for every text and non-text element, and reports each failure with the measured ratio, the elements involved, and developer fix guidance you can apply directly. It surfaces WCAG issue detection and EAA readiness signals alongside the specific CSS-level changes that resolve them, so contrast work moves from guesswork to a clear checklist. For larger sites, the WordPress plugin and PDF reports make it easy to track progress and share results with stakeholders.

AccessGuard provides an accessibility scanner, WCAG issue detection, EAA readiness signals, and developer fix guidance. It is a tool to help you find and improve accessibility issues. It is not legal advice and does not guarantee legal compliance. For questions about your specific obligations under the European Accessibility Act or any other law, consult a qualified professional.

Frequently asked questions

What contrast ratio do I need to pass WCAG?

At Level AA, normal text needs at least 4.5:1 against its background, large text (24px, or 18.66px when bold) needs at least 3:1, and user interface components and meaningful graphics need at least 3:1. Level AAA raises normal text to 7:1 and large text to 4.5:1.

How is a color contrast ratio calculated?

Each color is converted to a relative luminance value using its linearized red, green, and blue channels (weighted 0.2126, 0.7152, and 0.0722). The ratio is then (lighter luminance + 0.05) divided by (darker luminance + 0.05), producing a value between 1:1 and 21:1.

Why does my light gray text fail even though it looks readable?

Readability on a calibrated monitor in a dark room is not the same as the measured ratio. A color like #999999 on white measures about 2.85:1, below the 4.5:1 minimum for body text. It can fail for users with low vision or on lower-quality or glare-affected screens even when it looks fine to you.

Does contrast apply to buttons, icons, and borders?

Yes. WCAG 2.1 Success Criterion 1.4.11 requires user interface components and meaningful graphics, such as input borders, focus indicators, icons, and chart elements, to reach at least 3:1 against adjacent colors. Purely decorative elements and logos are exempt.

Do disabled elements need to meet contrast requirements?

No. Inactive or disabled controls are explicitly exempt from the contrast requirements. However, any text or control a user can still read or interact with, including hover, focus, and error states, must meet the applicable ratio.

Does passing a contrast checker make my site legally compliant?

No. A contrast checker verifies specific WCAG ratios and helps you improve accessibility, but it does not certify legal compliance. AccessGuard provides scanning, WCAG issue detection, EAA readiness signals, and fix guidance only. For legal questions, consult a qualified professional.

Important: AccessGuard performs automated accessibility checks and provides technical guidance based on common WCAG-related issues. Automated testing cannot detect every accessibility barrier and does not replace manual testing, user testing, or legal review. AccessGuard does not guarantee legal compliance.

More accessibility checkers

Scan your site now

Free, in a real browser, with a clear fix plan.

Scan my website