ContrastKitWCAG 2.2

Color Contrast Checker & Accessibility Toolkit

Test foreground and background colors against WCAG 2.2 AA and AAA standards, evaluate full palettes with an NxN contrast matrix, heal failing colors with smart auto-fix suggestions, and preview real-world UI components in 100% browser memory.

Quick Presets:

Color Pair Inputs

Luminance: 0.015
rgb(23, 23, 23)hsl(0, 0%, 9%)
Luminance: 1.000
rgb(255, 255, 255)hsl(0, 0%, 100%)
Contrast Ratio
16.42:1PASS AAA
APCA Lc (WCAG 3)
Lc -102.5
Enhanced Perceptual
1:1 (Fail)3.0:1 (UI/Large)4.5:1 (AA)7.0:1 (AAA)21:1
Normal Text (AA)
Body copy < 18pt (Req: 4.5:1)
PASS
Normal Text (AAA)
Enhanced reading (Req: 7.0:1)
PASS
Large Text (AA)
≥ 18pt or ≥ 14pt bold (Req: 3.0:1)
PASS
Large Text (AAA)
Enhanced headlines (Req: 4.5:1)
PASS
Non-Text UI Components (WCAG 2.2 SC 1.4.11)
Input borders, focus rings, buttons, icons (Req: 3.0:1)
PASS
Smart Color-Fix Suggestion Engine

Auto-Heal Failing or Suboptimal Contrast

Target:

The algorithm preserves your brand's unique hue and chroma while calculating the minimal lightness shift needed to pass accessibility standards.

Option A

Adjust Foreground Only

Keeps surface fixed, tweaks text lightness.

Suggested FG: #0000004.52:1
Option B

Adjust Background Only

Keeps text fixed, tweaks surface lightness.

Suggested BG: #ffffff4.52:1
Option C

Symmetrical Balance

Adjusts both colors equally towards compliance.

Balanced Shift4.55:1

Real-World Component Sandbox

Preview live text, buttons, form inputs, borders, and badges rendered with your active colors.

Stage:
Large Text Headline (18pt / 24px+)

The Quick Brown Fox Jumps Over The Lazy Dog

This is standard body copy (< 18pt) testing normal text contrast. Under WCAG 2.2 AA, this paragraph requires a 4.5:1 minimum ratio against the background. For enhanced readability under AAA, it demands at least 7.0:1.

Interactive Buttons & Non-Text UI Contrast

The border must maintain at least 3.0:1 against both the surrounding surface and the interior well.

Status Indicators & Cards
Active Filterwcag-compliant

Export Accessible Color Tokens

Copy ready-to-use variables into your stylesheet or design system.

:root {
  --color-foreground: #171717;
  --color-background: #ffffff;
  --color-contrast-ratio: 16.42;
}
Copied to clipboard!

Engineered for Designers, Developers & Design Systems

Everything you need to audit, fix, and ship accessible color pairings across web apps, UI libraries, and digital products without legal compliance surprises.

A11Y Standard

WCAG 2.2 AA & AAA Standards

Evaluates exact mathematical contrast thresholds for normal body text (4.5:1), large headlines (3.0:1), and enhanced AAA compliance (7.0:1).

Design Systems

NxN Color Palette Matrix

Audit entire brand palettes at once. View every foreground-background pairing in an interactive grid, filter by passing status, and spot toxic combinations.

Smart Algorithm

Smart Color-Fix Auto-Heal

Failing WCAG requirements? Automatically calculate the nearest passing color while locking your original hue and saturation. Adjust foreground, background, or both.

Interactive UI

Non-Text UI Contrast (SC 1.4.11)

Test button borders, input focus rings, radio states, icons, and graphical components against adjacent backgrounds with the required 3.0:1 ratio.

Live Preview

Real-World Component Sandbox

Inspect live rendered paragraphs, headings, solid & ghost buttons, inputs, pills, and hyperlinks across light and dark surface modes simultaneously.

Developer Ready

1-Click Multi-Format Export

Export accessible token pairs to pure CSS variables, Tailwind CSS v4 `@theme`, Tailwind CSS v3 `tailwind.config.js`, or Figma-compatible Design Tokens JSON.

The Definitive Guide to WCAG 2.2 Color Contrast & Design System Accessibility

Digital accessibility is no longer merely a design preference; it is a fundamental civil right and an international legal requirement. Learn how WCAG 2.2 calculates contrast ratios, why non-text UI contrast is the most overlooked failure, and how to build resilient, accessible design systems.

1. How WCAG 2.2 Calculates Contrast Under the Hood

The Web Content Accessibility Guidelines (WCAG) determine color contrast by computing the difference in Relative Luminance between two colors. Relative luminance measures the relative brightness of any point in a colorspace, normalized to 0 for the darkest black and 1 for the lightest white.

Because the human visual cortex does not perceive red, green, and blue light with equal intensity (the eye is dramatically more sensitive to green wavelengths than blue), WCAG 2.2 weights RGB channels using the standardized sRGB coefficients:

Step 1: Convert sRGB 8-bit to Linear Luminance:

If (Channel / 255) ≤ 0.04045: C_linear = (Channel / 255) / 12.92

Else: C_linear = (((Channel / 255) + 0.055) / 1.055) ^ 2.4

Step 2: Calculate Relative Luminance (L):

L = 0.2126 × R_linear + 0.7152 × G_linear + 0.0722 × B_linear

Step 3: Calculate Contrast Ratio:

Ratio = (L1 + 0.05) / (L2 + 0.05) [where L1 ≥ L2]

The constant offset + 0.05 accounts for ambient flare in standard viewing conditions. The resulting ratio ranges from 1.00:1 (identical colors with zero contrast) up to 21.00:1 (pure black on pure white).

2. WCAG 2.2 Compliance Thresholds Explained

Understanding the distinct thresholds required for different elements across your interface prevents both inaccessible text and overly restrictive design limitations:

Level AA (Legal Benchmark)

Baseline Standard for ADA & EAA

  • Normal Text (< 18pt): 4.5:1 minimum ratio.
  • Large Text (≥ 18pt or ≥ 14pt bold): 3.0:1 minimum ratio.
  • UI Components & Graphics (1.4.11): 3.0:1 minimum against adjacent surface.
Level AAA (Enhanced)

Optimal Legibility for Low Vision

  • Normal Text: 7.0:1 minimum ratio.
  • Large Text: 4.5:1 minimum ratio.
  • Required for specialized medical, governmental, or dedicated elderly platforms.

3. Non-Text UI Contrast (Criterion 1.4.11): The #1 Overlooked Accessibility Trap

While many design teams ensure their body text meets 4.5:1, automated web audits report that over 78% of websites fail WCAG Criterion 1.4.11 (Non-text Contrast). This criterion requires a 3.0:1 ratio for:

  • Form Input Boundaries: If an input field does not have a 3:1 border contrast against the surrounding page background, users with low vision cannot perceive where the interactive target begins.
  • Focus Indicators: Keyboard navigation focus rings must have at least 3:1 contrast against both the focused element and the adjacent page background.
  • Standalone Icons: Icons that convey standalone information without accompanying text labels (e.g., shopping cart, search magnifying glass, burger menu) must achieve 3:1.
  • Selection & Toggle Controls: Checkbox ticks, radio active dots, and toggle switch handles must clearly contrast with their background wells.

4. The Future: APCA (Advanced Perceptual Contrast Algorithm)

WCAG 2.x's contrast algorithm, while simple and standardized, possesses known flaws. For example, it treats dark-on-light and light-on-dark symmetrically, whereas the human eye experiences irradiation (white text on a black background appears bolder and bleeds into the dark surround).

The APCA (Advanced Perceptual Contrast Algorithm) is the candidate contrast method developed for future WCAG 3.0 guidelines. Rather than outputting a simple ratio like 4.5:1, APCA outputs a Lightness Contrast (Lc) value from -108 to +106. ContrastKit calculates and displays both metrics, allowing design teams to future-proof their component libraries today.

5. Step-by-Step Workflow: Auditing and Fixing Your Design System

  1. Input Brand Colors: In the Pair Inspector, enter your foreground (text/icon) and background hex, rgb, or hsl values, or pick from popular curated presets.
  2. Check Instant WCAG 2.2 Metrics: Review the calculated ratio and live pass/fail badges for normal text, large headings, and non-text UI borders.
  3. Test in the Component Sandbox: Scroll to the real-world sandbox to observe how the color pair behaves in paragraphs, buttons, focusable form inputs, and badges in light and dark themes.
  4. Deploy the Smart Color-Fix Engine: If your pairing fails, click "Fix Foreground", "Fix Background", or "Fix Both". ContrastKit calculates the minimal lightness change required to reach compliance while preserving your brand's exact hue.
  5. Run the NxN Palette Matrix: Switch to the Palette Matrix view, enter your entire color palette array, and instantly identify which pairings are safe for text vs background vs surface cards.
  6. Export Code Tokens: Copy the accessible colors directly as CSS Custom Properties, Tailwind CSS v4 @theme, or JSON tokens for Figma.

6. Comparison Matrix: ContrastKit vs Competitors

Capability / FeatureContrastKitWebAIMCoolors CheckerBasic CLI Checkers
WCAG 2.2 AA / AAA ChecksFull SupportWCAG 2.1 onlyBasicPartial
NxN Palette Contrast MatrixInteractive GridNone (Single pair)NoneRaw JSON
Smart Color-Fix (Auto-Heal)FG / BG / SymmetricalManual slidersNoneNone
Non-Text UI Validation (SC 1.4.11)Yes (Inputs, Buttons, Rings)Graphical objects onlyNoNo
Real-World Component SandboxYes (Light & Dark UI)Static sample textSingle cardNo visual UI
APCA (WCAG 3.0) CalculationIncludedNoNoRare
Export (Tailwind, CSS, JSON)1-Click Multi-FormatNoURL onlyManual
100% Client-Side PrivacyZero tracking / OfflineServer queriesHeavy Ad trackersLocal

7. Best Practices for Accessible Digital Products

Avoid Pure Black on Pure White (#000 on #fff): While 21:1 passes all tests with flying colors, maximum contrast can produce visual vibration and eye strain (halation) for readers with dyslexia or astigmatism. Industry-leading design systems use subtle ink tones like #171717 on #fafafa (15.8:1), which feels softer yet remains effortlessly compliant.

Never Rely Exclusively on Color: Color contrast alone does not satisfy WCAG Success Criterion 1.4.1 (Use of Color). Critical links in body text should carry an underline or a minimum 3:1 luminance contrast against surrounding non-link text plus a distinguishable hover/focus state. Form errors should pair red outlines with descriptive error icons and clear text messages.

Store Accessible Tokens at the Core: Rather than manually checking colors on every screen, bake accessible pairings directly into your design system tokens (e.g. surface-primary and text-on-primary). When engineers consume designated token pairs, accessibility is maintained automatically.

Frequently Asked Questions

Clear answers on WCAG 2.2 contrast compliance, legal implications, color math, and the Smart Color-Fix algorithm.

What is the difference between WCAG 2.2 AA and AAA standards?
WCAG 2.2 Level AA is the universally adopted legal benchmark for digital accessibility under regulations like the ADA, Section 508, and the European Accessibility Act (EAA). Level AA requires a 4.5:1 contrast ratio for normal body text (< 18pt or < 14pt bold), 3.0:1 for large text (≥ 18pt or ≥ 14pt bold), and 3.0:1 for user interface components and graphical objects. Level AAA represents enhanced accessibility, requiring 7.0:1 for normal text and 4.5:1 for large text to maximize legibility for users with low vision or color perception variations.
What constitutes 'Large Text' under WCAG guidelines?
Under WCAG 2.2, large text is officially defined as at least 18pt (approximately 24 CSS pixels at standard 96 DPI) or at least 14pt bold (approximately 18.66 CSS pixels with font-weight 700+). Because larger letterforms have wider stroke widths, they remain legible at lower contrast ratios, lowering the AA requirement from 4.5:1 to 3.0:1.
How does Non-Text UI Contrast (WCAG 2.2 Success Criterion 1.4.11) work?
Criterion 1.4.11 mandates that visual boundaries of interactive components (such as form inputs, radio buttons, checkboxes, and toggle switches) and essential graphical objects (such as standalone icons, charts, and focus rings) must achieve at least a 3.0:1 contrast ratio against their adjacent background colors. This prevents critical interactive affordances from vanishing for visually impaired users.
How does the Smart Color-Fix suggestion algorithm work?
ContrastKit's Smart Color-Fix algorithm calculates the mathematically minimal adjustment needed to elevate a failing color pair to compliant thresholds (such as 4.5:1 for AA or 7.0:1 for AAA). By operating in HSL (Hue, Saturation, Lightness) color space, it holds your brand's unique hue and chroma intact while fine-tuning lightness. You can choose to adjust solely the foreground, solely the background, or symmetrically adjust both.
What is the Palette Contrast Matrix and how do I use it?
The Palette Contrast Matrix calculates every two-color pairing across an entire design system palette in an N × N interactive grid. Instead of testing one foreground and background pair at a time, you can input all your theme tokens (e.g., surface, primary, neutral, border, accent) and immediately see which combinations pass WCAG AA or AAA, filter by passing or failing pairs, and copy compliant token pairs into your stylesheet.
What is APCA (Advanced Perceptual Contrast Algorithm)?
APCA is the candidate contrast method developed for future WCAG 3.0 standards. Unlike the classic WCAG 2 mathematical ratio (which only considers relative luminance), APCA evaluates human spatial vision, font weight, text size, and perceptual light adaptation to determine true perceived readability. ContrastKit displays the APCA Lc score alongside standard WCAG 2.2 ratios for modern design system teams.
Is any color or code data uploaded to external servers?
No. ContrastKit is 100% client-side and privacy-first. All color conversions, WCAG relative luminance math, matrix computations, and code exports execute strictly in your local browser memory. No data, files, telemetry, or server requests are ever transmitted.
Can I export accessible colors directly into Tailwind CSS or Figma?
Yes. ContrastKit provides instant 1-click export formats: CSS Variables (`:root`), Tailwind CSS v4 `@theme` tokens, Tailwind CSS v3 `tailwind.config.js` objects, and Design Tokens JSON format compatible with Figma Tokens and Style Dictionary.