This color contrast checker is a professional accessibility testing tool for web designers and developers. Ensures your color combinations meet WCAG standards.

Key Features

• Dual contrast algorithms: Traditional WCAG 2.1 and modern APCA calculations

• Real-time preview with multiple text sizes (12px to 24px) and font weights

• Color blindness simulation for 8 different vision types

• Smart recommendations when colors fail accessibility standards

• Format flexibility: Switch between HEX, RGB, and HSL with one click

Quick Testing Tools

Preset combinations for common scenarios:

• Brand colors (blue, red, green themes)

• High contrast pairs

• Subtle professional combinations

One-click color swap between foreground and background. Perfect for testing inverted themes.

Compliance Standards

Tests against WCAG AA (minimum legal requirement) and WCAG AAA (enhanced accessibility).

• AA: Required for government sites, e-commerce

• AAA: Recommended for medical content, educational materials

Technical Details

Calculates precise contrast ratios using relative luminance. Provides actionable feedback with specific color suggestions when combinations fail standards.

Built for professionals who need reliable, fast accessibility testing. No account required. Works offline.

What Is a Color Contrast Checker?

A color contrast checker is a tool that measures the luminance ratio between two colors, typically a foreground color (text or icon) and a background color, and outputs a numerical contrast ratio on a scale from 1:1 to 21:1.

A ratio of 1:1 means both colors are identical. Black text on a white background produces the maximum ratio of 21:1. Everything else falls somewhere between those two extremes.

The tool exists because human perception of color is unreliable. Two colors that look "different enough" to one person can be completely unreadable to someone with a color vision deficiency or low vision. A contrast checker removes the guesswork by producing an objective, numerical result against known pass/fail thresholds.

Low contrast text is the single most reported accessibility failure on the web. According to WebAIM's 2025 Million report, 79.1% of homepages fail minimum color contrast requirements, making it the most persistent accessibility issue across the entire web.

Checkers accept color values in hex (e.g., #FFFFFF), RGB, and HSL formats. Some tools also support OKLCH and CSS named colors. The output is always the same: a contrast ratio number, plus a pass or fail result for each WCAG level.

Understanding how a checker works fits within the broader context of color theory and accessible design. It is one of the most practical tools in any designer or developer's workflow.

How Does a Color Contrast Checker Calculate Contrast Ratios?

The calculation behind every contrast checker comes from a W3C-defined formula that uses relative luminance, not perceived brightness or hue. Two completely different colors can produce the same contrast ratio if their luminance values are identical.

The formula is: Contrast Ratio = (L1 + 0.05) / (L2 + 0.05), where L1 is the relative luminance of the lighter color and L2 is the relative luminance of the darker color (W3C, WCAG 2.2).

How Relative Luminance Is Calculated

Relative luminance converts each RGB channel to a linearized value, then applies weighted coefficients to account for how the human eye perceives each channel differently.

The luminance formula: L = 0.2126R + 0.7152G + 0.0722B after gamma correction. Green carries the heaviest weight because human eyes are most sensitive to green light. Blue carries the lowest.

Before applying those coefficients, each channel value goes through gamma correction. Channel values above the sRGB threshold of 0.03928 follow the formula ((channel + 0.055) / 1.055) ^ 2.4. Values at or below that threshold are divided by 12.92 directly. This step converts the non-linear sRGB color space to linear light values.

The 0.05 offset added to both luminance values in the final ratio prevents division by zero and sets the minimum possible ratio at 1:1 (when both colors are black).

Why Opacity and Transparency Cause Errors

Opacity creates the single most common calculation mistake. When text uses a semi-transparent color, its actual rendered color depends on the background beneath it.

A checker tool only knows what hex or RGB values you enter. It has no way to calculate the composited color unless you flatten the opacity first. Enter a foreground with opacity: 0.7 and you get a wrong result every time.

The fix: calculate the composited color value manually (or use a tool with an eyedropper that samples the rendered screen), then enter that final hex into the checker.

Luminance vs. Hue: What the Formula Ignores

Research from 1991 (Knoblauch et al.) found that luminance affects reading performance far more than hue or saturation. This is why the WCAG formula ignores hue entirely.

The practical consequence: a bright red on a bright green background might look high contrast to a person with normal color vision but can produce a contrast ratio below 2:1. This is also why checking for color contrast alone does not cover color blindness scenarios. Two colors with enough luminance difference pass the formula even if users with deuteranopia cannot distinguish them by hue.

What Are the WCAG Contrast Ratio Requirements?

WCAG defines minimum contrast ratios across 2 conformance levels, AA and AAA, with different thresholds for text size and element type. The thresholds apply to the foreground-to-background ratio produced by a contrast checker.

Requirement	WCAG AA	WCAG AAA
Normal text (under 18pt / 14pt bold)	4.5:1	7:1
Large text (18pt+ / 14pt+ bold)	3:1	4.5:1
UI components and graphics	3:1	No defined AAA level
Decorative elements, logotypes	Exempt	Exempt

These thresholds apply to WCAG 2.1 and 2.2. Contrast requirements were first introduced in WCAG 2.0 in 2008 and have remained unchanged across subsequent versions (W3C, WCAG 2.2).

WCAG AA vs. AAA: Which Applies to Your Project?

AA is the legal baseline. The U.S. DOJ's April 2024 final rule under Title II of the ADA mandates WCAG 2.1 Level AA compliance for state and local government websites and apps, with deadlines staggered between 2026 and 2027. Over 4,000 ADA web accessibility lawsuits were filed in federal courts in 2024, with insufficient color contrast listed as a barrier in many filings.

AAA is aspirational for most projects. No law currently mandates AAA compliance across the board. The standard is appropriate for healthcare, legal, and government information where maximum readability matters and the audience includes people with severe low vision.

Key difference: failing AA creates legal exposure. Failing AAA does not, though it represents a missed standard for usability.

What WCAG 3.0 and APCA Change About Contrast

WCAG 3.0 is expected to replace the current luminance-ratio formula with the Advanced Perceptual Contrast Algorithm (APCA), developed by Andrew Somers. APCA factors in font weight, font size, and display polarity (light-on-dark vs. dark-on-light), producing an Lc score rather than a ratio.

The current WCAG formula produces "false passes" where two colors meet the 4.5:1 threshold but remain hard to read in practice. APCA addresses this by modeling how the human visual system responds to text on screen.

WCAG 3.0 is still a Working Draft as of 2026. The W3C does not expect it to reach final Recommendation status until the late 2020s, likely between 2028 and 2030. WCAG 2.2 Level AA remains the operative legal standard now.

What Types of Color Contrast Does the Checker Evaluate?

Most people run a contrast check on body text and stop there. That covers one WCAG criterion (1.4.3) but leaves several others unchecked.

Contrast checkers evaluate 3 distinct categories: text contrast, non-text contrast, and contrast across interactive states. Each maps to a different WCAG success criterion with a different pass threshold.

Text Contrast

Text contrast covers all readable content: body copy, headings, labels, captions, and linked text. The minimum is 4.5:1 for normal text and 3:1 for large text under WCAG 1.4.3 (Level AA).

One edge case most teams miss: placeholder text inside form fields. Placeholder text frequently fails at ratios between 1.8:1 and 2.5:1 because it is intentionally styled lighter than real input text. It still needs to meet the 4.5:1 minimum.

Linked text that uses color alone to distinguish itself from surrounding text also falls under a separate rule (WCAG 1.4.1). A contrast checker tells you the ratio but does not flag the color-only distinction issue automatically.

Non-Text Contrast

Non-text contrast covers UI components and graphical objects under WCAG 1.4.11 (Level AA), introduced in WCAG 2.1. The minimum ratio is 3:1, lower than text because graphical elements tend to be larger.

This applies to:

• Icon borders and fills that convey meaning
• Input field borders (the boundary that defines the form control)
• Focus indicators and keyboard focus rings
• Data visualization elements when color encodes data values

Decorative icons that carry no functional meaning are exempt. An icon that replaces a text label is not exempt.

Contrast Across Interactive States

Buttons, links, and form controls exist in multiple states: default, hover, focus, active, disabled, and error. Each state needs a separate contrast check.

Disabled state is explicitly exempt under WCAG 1.4.3. However, components that appear disabled but remain interactive are not exempt, and this distinction trips up a lot of teams during audits.

Focus indicators deserve special attention since WCAG 2.2 introduced Success Criterion 2.4.11 (Focus Appearance), which adds minimum size and contrast requirements for keyboard focus rings that go beyond earlier guidance.

Which Color Contrast Checkers Are Most Accurate?

All major tools use the same W3C luminance formula. Accuracy differences between them are minimal for solid-color pairs. Where they diverge is in features, workflow integration, and handling of edge cases like gradients and real-screen colors.

Tool	Type	Best For	Handles Real Screen Colors
WebAIM Contrast Checker	Browser-based	Quick hex/RGB checks	No
TPGi Colour Contrast Analyser	Desktop app	Sampling live screen colors	Yes (eyedropper)
Adobe Color	Browser-based	Design workflows, palette testing	No
Chrome DevTools	Built-in browser	In-browser element inspection	Partial
Stark (Figma/Sketch plugin)	Design plugin	Pre-handoff design audits	No
Polypane	Browser app	APCA and WCAG side-by-side	Partial

Browser Extension vs. Desktop App vs. Design Plugin

The right tool depends on when in the workflow you are checking.

Design plugin (Stark, A11y for Figma): catches failures before any code is written. Best used during component and palette creation. Works on design file colors directly, not rendered screen output.

Desktop app (TPGi Colour Contrast Analyser): uses a screen eyedropper to sample the actual rendered color on any application or webpage. The only option when checking rendered gradients, overlaid elements, or colors affected by CSS transforms.

Browser DevTools (Chrome, Firefox): shows contrast ratio directly in the color picker and flags failing elements in the accessibility tree. Practical for quick checks during development but does not produce a full audit report.

Wix is a notable example of CMS-level contrast work: only 20% of Wix websites fail the Lighthouse color contrast test, compared to a median failure rate of 70% among the most-used CMS platforms (HTTP Archive Web Almanac, 2024).

How Do You Check Contrast for Text on Images or Gradients?

This is the edge case that breaks standard contrast checking. Images and gradients have no single background color value, so you cannot enter a hex code and get a reliable result.

The WCAG standard requires that contrast holds across the full range of background variation beneath the text. A gradient that goes from dark to light still needs to meet the minimum ratio at every point the text crosses.

The Worst-Case Pixel Method

Sample the pixel directly behind the text where the background color is closest to the text color. That is the worst-case point. If the contrast ratio passes at the worst-case pixel, it passes everywhere.

TPGi Colour Contrast Analyser handles this with its eyedropper tool, which samples actual screen pixels. For design file work, the same logic applies manually: identify the lightest background area the text crosses, sample that color, run the check.

Practical method for gradients:

• Identify the lightest point of the gradient beneath the text
• Sample that color value using an eyedropper
• Enter it as the background in any standard contrast checker
• If it passes at that point, the full gradient passes

CSS Overlay Approach for Guaranteed Compliance

The most reliable fix for text on images is a semi-transparent overlay. A solid or gradient band behind the text, dark or light depending on text color, controls the effective background and makes the contrast predictable and stable.

After adding the overlay, the composited color still needs to be sampled from the rendered screen output, not calculated theoretically from the overlay's opacity value. CSS rendering, color mixing, and screen gamma all affect the final pixel color.

Text on gradient backgrounds is common in hero sections, card overlays, and badge designs. Getting the contrast right at the design stage is much faster than fixing it after development.

What Contrast Ratio Failures Are Most Common in Web Design?

Low contrast text is the top accessibility failure year after year. According to WebAIM's 2025 Million report, 79.1% of homepages still fail minimum contrast requirements, averaging 29.6 contrast failures per page.

Most of those failures follow predictable patterns. Knowing them makes audits faster.

Light Gray Text on White Backgrounds

This is the most common failure across real sites. Light gray on white looks clean and modern in design mockups but regularly produces ratios below 3:1. Medium gray (#767676) on white is exactly the 4.5:1 minimum. Anything lighter than that fails.

The pattern shows up most in secondary copy, captions, metadata text, and timestamps. Designers lighten these intentionally to create visual hierarchy, but the lightening often goes too far.

Placeholder Text and Disabled Form Fields

Placeholder text fails on the majority of sites checked in real audits. The default browser styling for placeholder text is often #999 on white, which produces a ratio of 2.85:1. That fails WCAG AA by a significant margin.

Disabled state text has no WCAG minimum, but components that look disabled while remaining interactive are not exempt. Teams frequently mark fields as "visually disabled" in a design system without removing the interactive behavior in code, creating both a contrast failure and a functional accessibility issue.

Link Text Without Underline

When links use color alone to distinguish themselves from surrounding body text, 2 conditions must hold: the link color must have a 4.5:1 ratio against the background, and the link color must have a 3:1 ratio against the surrounding non-link text color.

Both conditions need to pass. Most sites check one but not both. A blue link on white might pass the background check but fail the 3:1 check against dark body text if the blue is too similar in luminance to the gray paragraph text.

Adding an underline removes this dual-check requirement entirely, which is why it remains the most robust approach for link differentiation.

Focus Indicators

Keyboard focus rings are frequently the worst-performing element in any contrast audit. Browser defaults are often removed with outline: none in CSS resets, then replaced with custom focus styles that were never contrast-checked.

WCAG 2.2 Success Criterion 2.4.11 added requirements that did not exist in earlier versions: focus indicators must have a minimum contrast of 3:1 against adjacent colors and a minimum area. Many sites that passed WCAG 2.1 audits fail WCAG 2.2 specifically because of this criterion.

How Does Color Blindness Affect Contrast Checking?

Approximately 300 million people worldwide have some form of color vision deficiency, roughly 8% of males and 0.5% of females (Colorblind.io, 2024).

Color contrast checkers measure luminance difference, not hue difference. That means a passing ratio score does not guarantee the colors are distinguishable to someone with deuteranopia or protanopia.

What the Luminance Formula Misses for Color-Blind Users

Red-green combinations are the classic problem. A bright red (#FF0000) on a bright green (#00FF00) produces a contrast ratio of only 1.29:1, which correctly fails the luminance check.

But some red-green pairs pass the luminance check while remaining completely indistinguishable to users with deuteranopia (affecting roughly 1% of males) or protanomaly (affecting approximately 6% of males), because those two conditions reduce green sensitivity without changing perceived luminance significantly.

The result: a color pair can pass WCAG AA and still cause confusion for a segment of your audience.

Tools That Simulate Color Vision Deficiency

Simulation tools convert your design into how it appears under specific color vision deficiency types. None of them replace a contrast checker but they catch what the luminance formula misses.

• Stark (Figma): 8 simulation modes including deuteranopia, protanopia, and tritanopia, applied directly in the design file
• Adobe Color: accessibility tools tab shows simulations for 3 deficiency types alongside contrast ratio
• Coblis: free browser-based simulator, accepts image uploads
• Chrome DevTools: built-in vision deficiency emulation under Rendering panel, works on any live page

Contrast Checking vs. Color Blindness Testing

Contrast checking answers: do these two colors have enough luminance difference?

Color blindness simulation answers: can users with CVD distinguish these two elements at all?

Both checks are needed. A passing contrast ratio is necessary but not sufficient for full color accessibility. The color psychology behind which hues you choose matters separately from whether the luminance ratio passes.

How Do You Integrate Contrast Checking Into a Design Workflow?

Contrast checking caught at the end of a project is expensive to fix. Caught at the token level, it costs almost nothing. The principle is simple: move the check earlier.

Automated tools catch only 30 to 40% of WCAG violations, according to research from Deque Systems and Carnegie Mellon University. Manual checks cover the rest. A workflow that relies on automation alone misses the majority of real failures.

Design Token and Palette Stage

Define accessible color pairs at the design token level before any component uses them. A color palette that documents approved foreground-background combinations removes guessing at every downstream step.

Document pairs explicitly in your brand style guide: "Primary 700 on White: 5.2:1, passes AA for normal text." Teams that skip this step repeatedly recreate the same failures across different components.

Figma Design Checks Before Handoff

Stark and A11y - Color Contrast Checker (both Figma plugins) flag contrast failures directly inside the design file.

Run checks at these stages:

• Component creation, before the component enters the shared library
• During design review, before developer handoff
• After any color or typography change to existing components

Catching a failure here is a color value change in Figma. Catching it after development is a code change, a design update, and a re-review cycle.

Automated Contrast Testing in CI/CD with axe-core

axe-core runs contrast checks programmatically against rendered pages and integrates into Jest, Cypress, or any CI/CD pipeline.

Configure Lighthouse CI with --assert.assertions.color-contrast=error to fail builds on contrast regressions. pa11y offers a similar command-line approach for teams not already using Lighthouse. Both tools flag the element, its selector, and the failing ratio in their output.

Important limitation: automated pipeline checks miss dynamically generated colors, user-generated content, and theme variations. Those need manual spot-checking at release stage.

Design System Token Documentation

Material Design and Fluent UI both define contrast tokens in centralized configuration files, letting thousands of components inherit consistent contrast rules from a single source (Nerd Level Tech, 2026). That model works for any design system, not just large ones.

Document every approved token pair with its ratio. When a designer picks a color that is not in the approved set, the gap is visible immediately rather than discovered during an audit.

What Is the Difference Between WCAG Contrast and APCA Contrast?

The current WCAG 2.x formula and APCA measure fundamentally different things. WCAG 2.x asks "what is the luminance ratio?" APCA asks "how readable is this text for a human viewer?"

Feature	WCAG 2.x Contrast	APCA (for WCAG 3.0)
Output	Ratio (e.g., 4.5:1)	Lc score (e.g., Lc 60)
Font weight considered	No	Yes
Font size considered	Only as size category	Continuous scale
Polarity (light/dark mode)	Not differentiated	Explicitly modeled
Legal status (2026)	Enforceable standard	Working draft only
Dark mode accuracy	Unreliable (overstates)	Accurate

Why WCAG 2.x Produces False Results in Some Cases

WCAG 2.x was written in 2008 for CRT monitors and core web fonts. The formula overstates contrast for colors near black, which means a 4.5:1 ratio with a near-black text color can be functionally harder to read than a 3.5:1 ratio with a mid-gray (APCA documentation, Andrew Somers).

Two colors with identical calculated ratios can produce dramatically different legibility if one pairing uses a thin 300-weight font and the other uses a bold 700-weight font. WCAG 2.x ignores this entirely. APCA adjusts the required Lc score based on font weight and size together.

How APCA Lc Scores Work in Practice

Lc 60 is the APCA threshold that roughly corresponds to comfortable reading for most users, regardless of which two colors produce it. The Lc value is perceptually uniform: Lc 60 represents the same perceived readability across the full range of available colors.

Tools supporting APCA today: the official APCA calculator at git.apcacontrast.com, Polypane (which shows WCAG and APCA results side by side), and the Bridge-PCA calculator for designers who want to check both standards simultaneously.

WCAG 3.0 is not expected to reach Recommendation status until 2028 to 2030 (W3C, 2026). WCAG 2.2 Level AA remains the legally enforceable standard today. Learning APCA now prepares teams for the transition without requiring any immediate changes to existing compliance work.

How Do You Fix a Color That Fails Contrast Requirements?

Most contrast failures have straightforward fixes. The goal is to change luminance while keeping hue close enough that brand guidelines remain intact.

HSL is the most practical color model for making these adjustments. Changing the L (lightness) value changes luminance directly and predictably, without altering hue or saturation.

Darkening Text on Light Backgrounds

Light gray text on a white background is the most common failure pattern. The fix is usually a lightness reduction of 5 to 15 percentage points in HSL.

WebAIM Contrast Checker includes a lighten/darken slider that adjusts the foreground or background incrementally until the ratio passes. It shows the hex value at the passing threshold, which you can drop directly into code or Figma. That workflow takes under a minute per color pair.

Rule of thumb: for text on white backgrounds, any foreground color with HSL lightness above 45% is worth testing. Most fail at 4.5:1.

Adjusting Colors Within a Brand Palette

Brand constraints make contrast fixes feel harder than they are. Hue is what makes a color recognizable as "your brand blue." Lightness is what makes it readable. Adjusting lightness by 10 to 20 points almost never changes brand perception meaningfully.

Approach for constrained palettes:

• Keep the hue value identical
• Reduce lightness until the ratio hits 4.5:1
• Check the new value against your tint and shade generator
• Add the adjusted value as an "accessible variant" token, not a replacement

Crux Collaborative's case studies show that most brands can maintain recognition with lightness adjustments of under 15 points on any primary color.

When Font Size Is the Easier Variable

Sometimes the color genuinely cannot change. A brand-mandated logo treatment, a partner color, or a third-party component with locked styles.

If the failing element is text and the ratio is between 3:1 and 4.5:1, increasing the font size to 18pt (or 14pt bold) shifts the requirement from the 4.5:1 threshold to 3:1. The color passes without any change to its value.

This only works for text. Non-text UI elements require 3:1 regardless of size, so large icons with a 2.5:1 ratio still fail even at 96px.

Does Passing a Contrast Check Guarantee Accessibility?

No. A passing contrast ratio confirms one success criterion. WCAG 2.2 contains 78 success criteria across levels A, AA, and AAA.

Automated tools, including contrast checkers, detect roughly 30 to 40% of total WCAG violations (Deque Systems, 2020; Carnegie Mellon University, 2022). The remainder require manual testing with assistive technologies and real users.

What a Contrast Check Does Not Cover

Passing contrast does not address:

• Keyboard navigation and focus order
• Screen reader compatibility and ARIA implementation
• Color-only information (WCAG 1.4.1 is separate from contrast)
• Motion and animation (WCAG 2.3.1, 2.3.3)
• Text alternatives for non-text content

A site can pass every contrast check and still fail 60% of WCAG requirements.

The Scope of Legal Compliance

ADA Title II compliance requires full WCAG 2.1 Level AA conformance, not just passing contrast ratios. Over 5,000 ADA digital accessibility lawsuits were filed in the United States in 2025, a 20% increase from 2024, with 69% targeting e-commerce companies (ContextQA, 2026).

A clean automated contrast scan does not produce a legal defense. Courts look at actual usability for people with disabilities, including screen reader testing and keyboard navigation, not scanner output alone.

What a Complete Accessibility Audit Requires

Automated scanning: axe-core, Lighthouse, or WAVE for code-detectable issues including contrast, missing alt text, and broken ARIA.

Manual expert review: keyboard-only navigation through all interactive flows, heading structure audit, and form label verification.

Assistive technology testing: screen reader testing with NVDA or JAWS on Windows and VoiceOver on macOS and iOS, covering the primary user journeys.

Contrast checking is the starting point of accessibility work, not the end of it. Getting color contrast right is the fastest, cheapest accessibility fix available. Everything else takes more time. But contrast alone does not make a product accessible.

FAQ on Color Contrast Checkers

What is a color contrast checker?

A color contrast checker is a tool that measures the luminance ratio between a foreground color and a background color. It outputs a contrast ratio between 1:1 and 21:1, then tells you whether that ratio passes or fails WCAG accessibility standards.

What contrast ratio do I need to pass WCAG AA?

Normal text requires a minimum ratio of 4.5:1 under WCAG 2.1 Level AA. Large text (18pt or 14pt bold) only needs 3:1. UI components and graphical objects also require 3:1 under Success Criterion 1.4.11.

Does a passing contrast ratio mean my site is accessible?

No. A passing ratio confirms one criterion out of 78 in WCAG 2.2. It does not cover keyboard navigation, screen reader compatibility, or color-only information. Automated contrast checks catch roughly 30 to 40% of total accessibility failures.

What is the difference between WCAG AA and AAA contrast?

AA requires 4.5:1 for normal text and 3:1 for large text. AAA raises those thresholds to 7:1 and 4.5:1 respectively. AA is the legal baseline in most regulations. AAA is recommended for healthcare and government content where maximum readability matters.

Can I check contrast for icons and UI components?

Yes. WCAG 1.4.11 (Non-text Contrast) requires a 3:1 minimum ratio for UI components and graphical elements that convey meaning. This covers input field borders, icons, focus indicators, and data visualization elements. Decorative icons with no functional role are exempt.

How do I check contrast on a gradient background?

Sample the worst-case pixel directly behind the text, where the background color is closest to the text color. Use TPGi Colour Contrast Analyser's eyedropper to capture the exact rendered value. If the ratio passes at that point, it passes across the full gradient.

Does color blindness affect contrast ratio results?

Partially. The WCAG formula measures luminance, not hue, so it partially accounts for color vision deficiency. But some red-green combinations pass the luminance check while remaining indistinguishable to users with deuteranopia. Run a color blindness simulation alongside any contrast check.

What is APCA and how is it different from WCAG contrast?

APCA (Advanced Perceptual Contrast Algorithm) factors in font weight, font size, and display polarity. WCAG 2.x uses a fixed luminance ratio that ignores typography entirely. APCA is the proposed contrast method for WCAG 3.0 but remains a working draft with no current legal status.

Which color contrast checker tool is most accurate?

All major tools use the same W3C luminance formula, so ratio accuracy is consistent. For solid color pairs, WebAIM Contrast Checker works fine. For rendered screen colors, gradients, and overlays, TPGi Colour Contrast Analyser is more reliable because its eyedropper samples actual screen pixels.

How do I fix a color that fails the contrast check?

Adjust the lightness value in HSL while keeping the hue identical. For text on white, darken the foreground until the ratio hits 4.5:1. If the color cannot change, increasing font size to 18pt shifts the requirement from 4.5:1 down to the large-text threshold of 3:1.