WCAG Contrast Checker for Text, UI, and Accessibility Reviews
This tool helps you test whether a text color and background color combination is readable and compliant with WCAG 2.1 contrast guidance.
It is designed for real product work — not just a single contrast number.
You can:
- compare foreground (text) vs background colors
- see the live contrast ratio instantly
- preview colors in a realistic UI card (headings, buttons, small text)
- check AA / AAA thresholds for text and large text
- review UI & graphics and focus indicator targets
- swap colors to test reverse combinations
- auto-fix text or background toward AAA (or AA when AAA is impossible)
- share tests via URL parameters (
fgandbg)
If you design interfaces, write CSS, build component libraries, or QA accessibility, this tool gives you a practical workflow for color contrast decisions.
What WCAG Means (and Why It Matters)
WCAG = Web Content Accessibility Guidelines
WCAG stands for Web Content Accessibility Guidelines.
These guidelines help teams make websites and apps usable for more people, including users with:
- low vision
- reduced contrast sensitivity
- color vision deficiencies (color blindness)
- age-related vision changes
- temporary vision challenges (glare, fatigue, low-quality displays)
Good contrast also improves usability for everyone — especially on mobile, outdoors, and low-brightness screens.
What “WCAG 2.1” stands for
WCAG 2.1 is a version of the guidelines that expanded on earlier versions (such as 2.0) with additional criteria, especially around mobile, low vision, and cognitive accessibility.
For color work, teams most often focus on contrast requirements because they directly affect:
- body text readability
- button labels
- form fields
- icons and controls
- focus outlines for keyboard users
In practice: if users can’t clearly distinguish text or UI states from their background, the interface becomes harder (or impossible) to use.
What This Tool Checks (At a Glance)
The checker evaluates your selected colors against common WCAG-related contrast targets and explains what each one means.
Included checks in this tool
- AA Normal Text → target 4.5:1
- AA Large Text → target 3.0:1
- AAA Normal Text → target 7.0:1
- AAA Large Text → target 4.5:1
- UI & Graphics → target 3.0:1 (common target for meaningful UI indicators/graphics)
- Focus Indicators → target 3.0:1 (keyboard focus visibility)
- Hover & Active States → practical reminder that changed states still need compliant contrast
- Exceptions → decorative content, logos, and many disabled states (typically exempt)
This is especially useful when you’re testing a color in multiple roles (text, button fill, border, focus ring, icon) instead of only checking one scenario.
Understanding Contrast Ratio (Plain English)
A contrast ratio compares how different two colors appear in terms of brightness (more precisely, relative luminance).
1:1= no contrast (same color)21:1= maximum contrast (pure black on pure white)
Higher contrast ratios usually mean better readability.
Common WCAG thresholds you’ll use most
- 4.5:1 → minimum for normal body text (AA)
- 3:1 → minimum for large text (AA) and many UI indicators
- 7:1 → stricter enhanced target for normal text (AAA)
Why large text gets a lower threshold
Larger and/or bold text is easier to see, so WCAG permits a lower minimum contrast ratio than normal body text.
Large Text vs Normal Text (WCAG Definitions)
WCAG generally treats text as “large” if it is at least:
- 18pt regular (roughly 24px), or
- 14pt bold (roughly 18.5px bold)
Everything smaller should be treated as normal text, which means you should aim for at least 4.5:1 (AA minimum), and often higher for better readability.
If you’re unsure, assume it’s normal text and test against 4.5:1.
How to Use This Contrast Checker
1. Set your Text Color and Background Color
Use either:
- the color pickers (fast visual testing), or
- the hex input fields (exact values for design tokens / CSS variables)
The tool validates the inputs and updates the preview instantly.
2. Read the live Contrast Ratio
At the top-right of the preview card, the tool shows the current contrast ratio (for example, 4.72:1).
This gives you an immediate answer before you even look at the detailed scorecards.
3. Check the WCAG 2.1 scorecards
The scorecards show pass/fail status for:
- AA / AAA text standards
- large text thresholds
- UI and focus indicator checks
- practical interactive state reminders
This makes it easier to decide whether the color pair is safe for:
- body text
- headings
- buttons
- icons
- outlines
- form fields
4. Use Swap Colors
Click Swap Colors to reverse foreground and background.
This is useful because contrast can be valid in one direction and still need visual testing in the reverse design context (for example, white text on blue vs blue text on white).
5. Try Auto Fix (Text or Background)
If the pair fails, use:
- Fix Text → adjusts the text color to improve contrast
- Fix Background → adjusts the background color instead
The tool attempts a smart fix and explains whether it reached:
- AAA (7:1), or
- a partial fix at AA (4.5:1) when AAA is not possible by changing only one color
Smart Auto-Fix: What It Actually Does
This tool doesn’t just jump to black or white immediately. It uses a practical strategy to preserve your chosen color direction when possible.
Auto-fix strategy (high level)
When you click Fix Text or Fix Background, the tool:
- Checks the current contrast ratio
- Tests the maximum possible contrast by moving the selected color toward lighter or darker extremes
- Tries to reach AAA (7:1) first
- If AAA is impossible, it tries AA (4.5:1)
- If even AA is impossible by changing only one color, it applies the best possible extreme and tells you to fix the other color
Why “partial fix” can happen
Contrast is a relationship between two colors. Sometimes one color is too constrained relative to the other.
Example: if a saturated mid-tone is paired with another difficult mid-tone, adjusting only the text may not create enough separation to hit 7:1 without changing the background too.
In that case, the tool clearly reports that it optimized the selected color and what threshold it reached.
Accessibility Beyond Text: UI, Focus, and States
A lot of contrast checkers only focus on body text. This tool goes further by helping you think about interface behavior.
UI Components & Graphics (3:1 target, common use case)
For many meaningful UI graphics and controls (such as icons, borders, input outlines, selected states), a 3:1 contrast target is commonly used so users can distinguish the element from adjacent colors.
Examples:
- input borders on a form background
- icon-only buttons
- checkbox/radio outlines
- chart markers that convey meaning
- tabs / segmented controls
Focus Indicators (keyboard accessibility)
Keyboard users rely on visible focus outlines to know where they are on the page.
If your focus ring blends into the background, users can get lost.
This tool includes a Focus Indicators check reminder with a 3:1 target so you can evaluate common focus ring colors early in design/dev.
Hover / Active States
When a button background darkens on hover or active state, the text inside must still meet contrast requirements.
A color pair that passes in the default state may fail on hover if you shift the background too far without adjusting the text.
This tool’s scorecards make that easy to think about while choosing token values.
What AA and AAA Really Mean in Product Work
AA (Recommended baseline for most projects)
AA is the practical baseline most teams target.
It’s typically the minimum standard for:
- body text
- buttons and labels
- form controls
- navigation links
- essential icons / UI indicators
If you’re shipping a production UI, AA should be considered the default starting point.
AAA (Enhanced readability)
AAA is stricter and often produces much stronger readability, especially for long-form text and readability-first interfaces.
AAA is excellent when:
- your app has lots of reading
- your audience includes older users
- you want extra margin for poor displays / glare / fatigue
- you care deeply about visual clarity and comfort
Not every design can hit AAA everywhere without brand compromises — but using AAA as a target for key text is often worth it.
Real-World Workflows for This Tool
1. Validate button text on brand colors
- Set Text Color to
#FFFFFF - Set Background Color to your brand primary (e.g.
#3B82F6) - Check AA/AAA for normal text
- If it fails, click Fix Background (or choose a darker token like 600/700)
This is perfect for deciding button colors in a design system.
2. Test light mode and dark mode tokens
Run the same text color against:
- light surfaces (
surface,card,muted) - dark surfaces (
surface-dark,panel-dark,overlay)
Then swap colors and test reverse contexts (e.g. colored text on neutral backgrounds vs neutral text on colored backgrounds).
3. QA focus rings
Use your focus ring token as the foreground and the page/background surface as the background.
Aim for 3:1 or stronger so keyboard focus is clearly visible.
4. Create accessible semantic tokens
Test and refine pairs for:
success+ textwarning+ textdanger+ textinfo+ text
This is especially important for badges, alerts, and toast notifications.
URL Parameters (Helpful for Team Reviews)
This tool can initialize colors from the URL query string:
fg= foreground / text colorbg= background color
Examples (conceptually):
?fg=FFFFFF&bg=3B82F6?fg=%23FFFFFF&bg=%233B82F6
Why this matters:
- designers can share a failing combo with developers
- QA can attach contrast test links to tickets
- teams can document approved color pairs
Best Practices for Accessible Color Systems
1. Don’t rely on color alone
Even with perfect contrast, color alone should not be the only signal.
Also use:
- text labels
- icons
- shapes
- underlines/patterns
- status copy (e.g. “Error”, “Success”)
This helps users with color vision deficiencies and improves clarity generally.
2. Test real UI contexts, not isolated swatches only
A contrast ratio is essential — but context matters too.
Check your colors in:
- small body text
- buttons with padding and shadows
- thin icons and borders
- different screen brightness levels
- hover / active / disabled / focus states
3. Be careful with semi-transparent overlays
Contrast can change dramatically when a color uses opacity over an image or tinted surface.
If you use transparency, test the actual composited result (or use solid token fallbacks for critical UI text).
4. Favor stronger contrast for long reading
Even if 4.5:1 passes AA, you may want 6:1+ or AAA (7:1) for body copy and documentation pages to reduce eye strain.
5. Build contrast checks into your token workflow
Before finalizing a color token set, validate common pairs:
- text on surface
- text on primary/secondary buttons
- border on surface
- focus ring on surface
- icon on muted backgrounds
This prevents accessibility issues from spreading across components.
Common Mistakes This Tool Helps Catch
“It looks fine on my monitor”
High-end displays and ideal lighting can hide contrast problems. WCAG checks give you a consistent baseline across users and devices.
Using brand colors directly for body text
Brand primaries often work better for accents/buttons than for body text. This checker helps you decide where a color is appropriate.
Forgetting hover/focus/active states
Teams often validate only the default button state and forget that state changes can break contrast. Use this tool as part of state token QA.
Thin text + borderline contrast
A ratio may technically pass, but thin fonts or small sizes can still feel hard to read. Aim above the minimum when possible.
Limitations and Important Notes
- This tool evaluates color contrast only; full accessibility includes keyboard support, semantics, labels, focus order, motion, and more.
- Contrast pass/fail does not guarantee overall usability — it is one (important) part of accessibility.
- Browser/device rendering, font weight, anti-aliasing, and size can affect perceived readability even when a ratio passes.
- Decorative elements, logos, and disabled controls may be exempt from some WCAG contrast requirements, but critical UI should still be readable.
Who This Tool Is For
- Frontend developers checking text/background pairs before shipping
- Designers building accessible color systems and components
- Indie makers who want simple, reliable accessibility QA
- Product teams documenting approved color combinations
- QA / accessibility reviewers testing regressions and state changes
If you use color in UI, you need contrast checks. This tool gives you a fast, practical workflow with AA/AAA guidance, UI-focused checks, and smart auto-fix suggestions.
Quick Accessibility Checklist
Before shipping a UI color pair, ask:
- Does normal text pass at least 4.5:1?
- Does large text pass 3:1 (or stronger)?
- Are focus indicators clearly visible (aim 3:1+)?
- Do hover/active states still pass after the color changes?
- Are important icons/borders/controls distinguishable?
- Am I relying on color alone to communicate meaning?
If the answer is “yes” to the right checks, you’re in much better shape for accessible design.