How to Check Color Contrast for Accessibility

Roughly 1 in 12 men and 1 in 200 women have some form of color vision deficiency. Millions more have low vision, aging eyes, or are viewing screens in bright sunlight. If your text does not have enough contrast against its background, these people cannot read it. Color contrast is not just a nice-to-have, it is a core accessibility requirement. A browser-based contrast checker handles the entire job locally without uploading any colors or data to a server.

What WCAG requires

The Web Content Accessibility Guidelines (WCAG) define minimum contrast ratios between text and its background:

"Large text" means 18px bold or 24px regular and above. The contrast ratio ranges from 1:1 (no contrast, white on white) to 21:1 (maximum contrast, black on white).

How to check contrast

1. Select your colors: enter the foreground (text) and background colors using HEX codes, RGB values, or color pickers.
2. Check the results: the tool instantly shows the contrast ratio and whether your combination passes WCAG AA and AAA for both normal and large text.
3. Adjust if needed: if the contrast fails, darken the text or lighten the background (or vice versa) until you pass the required level.

A brief history of color contrast standards

Before WCAG, web accessibility was a patchwork of vendor-specific rules. The W3C published WCAG 1.0 in 1999, with contrast guidance but no specific ratio. WCAG 2.0 (2008) introduced the 4.5:1 / 7:1 formula based on color science from Dr. Lillian Yetenekian and the IBM Research lab, with input from low-vision researchers. The formula is designed so that a person with 20/40 vision (mild low vision) can read AA-compliant text, and a person with 20/80 vision (significant low vision) can read AAA-compliant text.

WCAG 2.1 (2018) added contrast requirements for UI components (3:1 for non-text), graphical objects, and focus indicators. WCAG 2.2 (2023) added more requirements around target sizes and focus visibility.

The current WCAG 3.0 working draft proposes a new contrast formula (APCA, Accessible Perceptual Contrast Algorithm) that better matches human perception, especially for darker text. APCA is not yet a W3C recommendation but is already supported by some tools as a preview.

Legal adoption of WCAG has been steady:

• US: Section 508 of the Rehabilitation Act (federal) and ADA case law require WCAG 2.0 / 2.1 AA
• EU: Web Accessibility Directive (2016/2102) and European Accessibility Act (2025) require EN 301 549, which is WCAG 2.1 AA
• UK: Public Sector Bodies Accessibility Regulations require WCAG 2.1 AA
• Canada: ACA (Accessible Canada Act) for federal sector, AODA (Ontario) for businesses
• Australia: DDA case law treats WCAG 2.1 AA as standard
• Japan: JIS X 8341-3:2016 (based on WCAG 2.0)

For most public-facing websites, WCAG 2.1 AA is the de facto legal minimum.

How contrast ratio is calculated

The contrast ratio is calculated using the relative luminance of each color:

1. Convert each color from sRGB to linear RGB (gamma correction)
2. Calculate relative luminance: L = 0.2126 R + 0.7152 G + 0.0722 B
3. Contrast = (L_lighter + 0.05) / (L_darker + 0.05)

The result is a number from 1 (no contrast) to 21 (maximum contrast). The 0.05 offsets prevent division by zero and slightly model the contribution of ambient light to perceived contrast.

The formula was deliberately designed to be deterministic and computable, so the same colors always produce the same ratio. It does not account for:

• Color blindness: a red/green pair may have a 7:1 ratio but be invisible to a person with red/green color blindness
• Font weight beyond bold: ultra-thin or hairline fonts need higher contrast
• Anti-aliasing artifacts: very thin strokes may appear lighter than the color value suggests
• Background patterns: gradients, images, or noise behind text degrade effective contrast

This is why WCAG checks are necessary but not sufficient. Visual review with diverse users (including those with color blindness) catches the rest.

Common contrast mistakes

Light gray text on white: #999999 on #ffffff has a ratio of only 2.8:1. This fails WCAG AA. It might look "clean" to a designer with perfect vision, but it is unreadable for many people.

Colored text on colored backgrounds: a blue button with white text often passes, but a green button with white text may not. Always check, you cannot judge contrast ratio by eye.

Placeholder text: form field placeholders are notoriously low-contrast. While WCAG does not strictly require placeholders to meet contrast ratios, users still need to read them.

Dark mode: designers often use medium gray text on dark gray backgrounds for a "subtle" look. This frequently fails contrast checks.

Text over images: text placed over a hero image often passes when the image is dark and fails when the image is light. Use a dark/light gradient overlay or solid backdrop behind text over images.

Brand color shifts: corporate identity often dictates a primary brand color. If that color fails as body text, use it for headings (large text, 3:1 threshold) and use a darker shade for body.

Link colors: links must be distinguishable from surrounding text. WCAG requires a 3:1 ratio between link and body text, plus another visual cue (underline, bold, or icon).

Focus indicators: the outline around a focused button or link must meet 3:1 contrast against its background. Browser default focus rings are usually safe; custom focus styles often fail.

Common pitfalls

• Testing only headings: contrast must be checked for every text size and weight combination on the page. Body text, captions, labels, buttons, icons, and form fields all need checking.
• Forgetting hover and active states: a link that passes contrast as default may fail when hovered (lighter color) or active (different background). Check all states.
• Disabled states ignored: WCAG explicitly excludes disabled states from contrast requirements, but accessible design still aims for some visible distinction.
• Translucent overlays: text on a 50%-transparent dark overlay behaves like its effective color, not the input color. Compose the effective color before checking.
• Anti-aliased thin text: 12px Inter Thin at 8.5:1 ratio is still hard to read. Check with the actual rendered font, not just the color value.
• HSL conversion drift: tweaking colors in HSL space can produce values that look similar but fail contrast. Always re-check after color adjustments.
• Brand colors locked by stakeholders: when a brand color cannot be changed, use it strategically (large text only) and choose a different color for body. Document the rationale for stakeholders.
• Forgetting print contrast: a website might pass contrast on screen but fail when printed in grayscale. Test printed output for documents intended for print.
• Text on video: video backgrounds shift constantly. Either pin a static frame, add a gradient overlay, or use a solid backdrop.
• Internationalization changes character density: Chinese, Japanese, Korean characters are denser than Latin. A 4.5:1 ratio that reads fine in English may strain readers of CJK languages at the same size. Bump up to 7:1 for international text.

Beyond WCAG: APCA and modern perceptual contrast

The Accessible Perceptual Contrast Algorithm (APCA) is a newer formula proposed by Andrew Somers for WCAG 3.0. Unlike the WCAG 2 formula, APCA:

• Accounts for font weight and size in the contrast score: thinner or smaller fonts need more contrast
• Uses non-linear perceptual scaling: matches how human vision actually responds to luminance
• Better handles dark backgrounds: WCAG 2 over-rates contrast on dark backgrounds; APCA corrects this
• Produces a polarity-aware score: positive for dark text on light background, negative for the reverse

APCA scores range roughly from -108 to +108. A score of 60 (positive or negative) is roughly equivalent to WCAG 2's 4.5:1. APCA is not yet legally required anywhere, but is being adopted by design systems like Material Design and IBM Carbon as a forward-looking standard.

For most practical purposes today, WCAG 2.1 AA (4.5:1 / 3:1) remains the legal and industry standard. Some teams use APCA in parallel as a quality check.

Tools and integrations

Integrate at least one automated tool in CI so contrast failures cannot ship undetected.

Tips

• Check every text/background combination: do not assume. Even experienced designers are surprised by which combinations fail.
• Test both themes: if your site has light and dark modes, check contrast in both. A color that works on white may fail on dark gray.
• Use your brand colors wisely: if your brand blue fails as text color, use it for larger elements (buttons, headers) where the large text threshold (3:1) applies, and use a darker shade for body text.
• Do not rely on color alone: in addition to sufficient contrast, never convey information by color alone. Use icons, text labels, or patterns alongside color to ensure everyone can understand the content.
• Test with simulators: a color blindness simulator shows what your design looks like to users with protanopia, deuteranopia, or tritanopia. Common pairs (red/green) often fail.
• Test in sunlight: take your phone outside on a bright day. Text that barely passes WCAG can become unreadable in direct sunlight. AAA contrast (7:1) is the practical minimum for outdoor visibility.
• Save accessible color palettes: build a palette where every text color passes against every background color. Constraint up front, no contrast surprises later.
• Educate stakeholders: stakeholders who demand a low-contrast brand color often change their mind when shown the design through a low-vision simulator.

Privacy and design data

The color contrast checker runs entirely in your browser. The colors and values you enter, the calculations, and the contrast results all stay on your device. Nothing is uploaded to a server, logged, or shared with anyone.

This matters less for individual colors (they are not secret) and more for batch checking or design-system work where you might paste a full brand palette, internal product mockup colors, or unreleased product UI specifications. Cloud contrast tools log every paste in their request logs, sometimes retain them for "service improvement," and could leak unreleased brand colors or UI designs. A browser-based checker has zero exposure: the colors never leave your machine.

Browser-based contrast checking also works offline once the page is loaded, useful for design reviews on airplanes, in secure environments without internet access, or anywhere you cannot or should not share design data with a third-party service.