Color Contrast Checker for WCAG AA and AAA text accessibility

• WCAG AA / AAA result matrix

  Review normal text, large text, and UI component results separately, so a color pair is not approved for the wrong use case.

• Multiple CSS color formats

  Paste values from design files, browser DevTools, CSS variables, or theme tokens using Hex, RGB, HSL, OKLCH, and related formats.

• Transparent color flattening

  When alpha is present, the tool composites the color against the effective background before calculating the contrast ratio.

• Readable foreground recommendation

  Compare black and white text on the current background and pick the safer baseline foreground color.

• AA / AAA fix candidates

  Generate foreground colors that meet the target threshold when the current pair fails contrast requirements.

• Copy-ready CSS and report

  Copy color declarations for implementation or copy a concise contrast report for reviews, tickets, and pull requests.

• Common interface presets

  Start from body text, links, buttons, warning badges, and dark mode combinations used in everyday UI work.

• Contrast ratio

  WCAG expresses contrast from 1:1 to 21:1. A ratio of 1:1 means almost no contrast; 21:1 is the maximum contrast, commonly black against white.

• Relative luminance

  Contrast is not calculated from raw RGB averages. WCAG converts sRGB values into relative luminance and then compares the lighter and darker colors.

• WCAG AA

  AA is the baseline target used by many websites and web applications. Normal text needs at least 4.5:1; large text and UI components commonly need 3:1.

• WCAG AAA

  AAA is stricter. Normal text needs 7:1 and is better suited for reading-heavy, public-service, education, documentation, and high-accessibility pages.

• Normal text and large text

  Normal text covers typical body copy and labels. Large text usually means 18pt regular or 14pt bold and above, which receives a lower threshold.

• UI component contrast

  Buttons, input borders, icons, selected states, and error states also need enough contrast to be distinguished, even when they are not text.

• Transparent color flattening

  Colors written with alpha, such as rgba, hsla, or OKLCH alpha values, depend on the surface underneath. Flattening gives a result closer to what users actually see.

• OKLCH and perceived lightness

  OKLCH tracks perceived lightness more predictably than HSL, which makes it useful for accessible color scales, dark mode palettes, and brand color systems.

1. 1

   Enter the text, icon, or control color as the foreground, then enter the surface color as the background.

2. 2

   Choose the target: normal text for body copy, large text for large labels or headings, and UI component for borders, icons, or control states.

3. 3

   Review the contrast ratio and WCAG result matrix to see which AA or AAA targets pass.

4. 4

   If the pair fails, try the recommended foreground color or generate AA / AAA foreground candidates.

5. 5

   Copy CSS or the contrast report for implementation notes, design review, QA tickets, or accessibility remediation records.

• Displays Normal Text AA, Normal Text AAA, Large Text AA, Large Text AAA, and UI Component AA in one result table.
• Shows flattened calculation colors for translucent overlays, glass-like cards, semi-transparent buttons, and dark mode layers.
• Swaps foreground and background with one action for inverse buttons, selected states, reversed labels, and dark theme variants.
• Copied reports include the foreground color, background color, contrast ratio, and each WCAG pass/fail result.
• Presets cover body copy, muted text, links, primary buttons, success and danger actions, warning badges, and dark mode text.
• Works as a practical helper for design system color tokens, brand color rollout, component acceptance, and accessibility fixes.
• Result messages distinguish between body-text-safe, large-text-only, UI-component-only, and not recommended color pairs.

When colors arrive from design files, screenshots, or legacy CSS in mixed formats, normalize them in Color Converter before testing the pair. If the same color keeps failing across states, build a cleaner scale in Palette Generator instead of patching one-off replacement colors across the interface.

• Design handoff checks

  Validate body text, headings, links, buttons, and status labels before a visual design moves into implementation.

• Component library QA

  Audit Button, Input, Badge, Alert, Tabs, and similar components across default, hover, disabled, selected, and error states.

• Dark mode color tuning

  Check body copy, secondary labels, borders, and icons on dark surfaces before shipping a dark theme.

• Brand color validation

  Test brand colors when they are used for buttons, links, and emphasis, then prepare compliant tonal alternatives.

• Accessibility issue remediation

  Use the tool to reproduce low-contrast issues reported by Lighthouse, axe, QA, or users and document the fix.

• Readable content pages

  Improve blogs, documentation, help centers, product pages, and long forms where sustained reading matters.

• Landing page and campaign checks

  Review hero copy, CTA buttons, pricing labels, and promotional banners where visual treatments can reduce readability.

• Admin dashboard theme maintenance

  Keep tables, filters, status indicators, sidebars, and analytics cards aligned to one contrast baseline.

• Make normal text AA the baseline for body copy, labels, helper text, and error messages; move reading-heavy areas toward AAA when practical.
• Do not rely on low contrast alone to communicate disabled state; combine contrast with opacity, icons, clear labels, or interaction behavior.
• In dark mode, adjust lightness steps before increasing saturation. Saturation alone rarely fixes readability.
• Check buttons, links, and status indicators in default, hover, focus, selected, error, and disabled states.
• Validate translucent overlays, glass-like cards, and floating panels against their actual page background.
• Store approved combinations as design tokens such as text-primary, text-muted, surface-card, and border-subtle.
• When brand colors fail contrast, create compliant tonal steps instead of choosing random near-matches per page.
• Add contrast checks to design review, pull request checklists, and release QA to catch regressions earlier.

• Passing WCAG contrast does not guarantee full accessibility. Semantic structure, keyboard access, focus visibility, error handling, and screen reader behavior still need review.
• Text over images, videos, complex textures, and gradients should be sampled from the real page area; a single background color is only an approximation.
• Generated AA / AAA candidates are useful for fast exploration, but final colors should still be reviewed against brand rules, theme scales, and visual hierarchy.
• Different displays, browsers, color management settings, and ambient light can change perceived readability; important pages should be checked on real devices.
• The tool evaluates the colors you enter. It does not automatically inspect your CSS variables, Tailwind config, or design token source.
• APCA and WCAG 2.x use different contrast models. This tool currently reports WCAG 2.x contrast ratios.