Choose the Correct WCAG Threshold Before Judging a Color
WCAG 2.2 distinguishes ordinary text, large text, and important non-text visual information. Level AA is a common accessibility target. Level AAA sets a stronger contrast threshold for text, although not every page can satisfy every AAA criterion. A ratio that passes for a large heading may still fail for a small button label.
Large text generally means at least 18pt (about 24 CSS px), or at least 14pt bold (about 18.7 CSS px). A 19px heading is not automatically large text if it lacks the necessary weight. Ordinary body copy, input labels, placeholder text, and most navigation items should be checked against the normal-text requirement. Decorative imagery, inactive controls, and logotypes have specific exceptions; do not use those exceptions to dismiss important interface content.
What the Contrast Ratio Tells You—and What It Does Not
The WCAG contrast ratio is derived from the relative luminance of the brighter and darker colors, using a defined calculation for sRGB values. Its theoretical range runs from 1:1 for identical colors to 21:1 for black against white. Hue differences alone are not enough: two colors can look very different while having nearly identical luminance.
A ratio is not a measure of font readability, text size, line spacing, color blindness, or overall usability. Passing the numerical requirement does not rescue a thin font placed over a distracting photo. Similarly, a 4.5:1 result for text cannot tell you whether a control has a visible focus indicator or a meaningful accessible name. Treat the ratio as one technical test within a wider accessibility review.
Compare Real Hex Values Rather Than Trusting Appearance
For a simple test, identify the exact CSS foreground color and the actual background color behind it. Hexadecimal values such as #FFFFFF and #767676 provide unambiguous inputs when the colors are opaque and the background is solid. The following illustrative ratios were calculated from the WCAG sRGB luminance formula, not captured from this site’s tool.
The difference between the first two gray shades is small but decisive. WCAG thresholds are not rounded up: a calculated ratio below 4.5:1 does not pass normal-text AA just because the displayed value looks close. Build some margin into design tokens rather than aiming for a borderline score that could be undermined by later color or background changes.
Measure the Colors the Visitor Actually Sees
The foreground color in a stylesheet is not always the final pixel color. A semi-transparent text color blends with the background beneath it. Shadows, overlays, gradients, background images, filters, and blended elements may alter visible contrast. A test that compares the unblended source hex values can therefore give the wrong answer for the rendered page.
For a translucent foreground, composite it against the effective background first, then evaluate the resulting visible color pair. A gradient needs checks at the weakest relevant point, not only at its darkest edge. For text over a photograph, examine every region the text can occupy across responsive layouts. When the background cannot be controlled, an opaque backing surface behind the text is usually easier to verify than a faint shadow.
Text Contrast and Button Visibility Are Different Checks
A button may have white text that passes against a dark blue fill, while the button itself disappears into a similarly colored page background. The text must satisfy the applicable text criterion. Separately, visual details essential to identifying the control or its state may need a 3:1 contrast ratio against adjacent colors under WCAG 1.4.11.
Do not assume every decorative border must reach 3:1. The requirement concerns visual information necessary for users to identify and operate a component. For example, the visible outline of a minimally styled text input may be the essential cue that the field exists, whereas a supplementary border around an obviously labeled button may not be its only identifying signal. Consider the actual visual role of each element.
Test focus indicators, selected states, checkbox marks, chart segments, and meaningful icons separately. If a colored icon communicates an error but nearby text already conveys the same information, its treatment may differ from an icon that carries the message alone. Underlining links and pairing status colors with labels or symbols also helps users who cannot reliably distinguish hues.
A Step-by-Step Audit for a WordPress Color Palette
- Collect the actual colors. Inspect the published site’s CSS or the computed styles in browser DevTools rather than relying on a design mockup.
- Group elements by purpose. Separate body text, headings, inputs, links, buttons, focus states, and meaningful graphics.
- Check each foreground/background pair. Record the ratio and the correct AA or AAA rule for that component.
- Inspect non-solid backgrounds. Account for transparency, color overlays, hover states, and responsive image crops.
- Improve failing combinations. Darken a text color, lighten a background, or introduce a clear border or backing surface as appropriate.
- Retest the final frontend. Check desktop and mobile layouts, dark mode where present, and keyboard focus visibility.
In WordPress, theme presets and global styles may define colors for many blocks at once. Changing a shared text token can be safer than patching dozens of individual paragraphs, but retest every template that uses it. Pay special attention to forms, announcement banners, price tables, navigation dropdowns, and text placed over featured images.
Common Reasons an Apparently Passing Palette Still Fails
One frequent mistake is testing text against the site’s page background when a card or modal has its own background. Another is assuming an accent color passes everywhere because it looks good on white: it may fail on a pale gray or tinted background. Hover styles can also turn dark text into low-contrast text without anyone noticing during the initial design review.
Watch for dark-mode styles that inherit a light-mode text token, muted placeholders that become nearly invisible, and disabled styling reused for active controls. A white label on a transparent button may look fine over a dark hero but become unreadable when the hero image crop changes on mobile. Use the browser’s computed styles and inspect the visually weakest state.
Automated checks cannot replace contextual judgment. A tool may evaluate specified color pairs correctly while overlooking text embedded in images, dynamically inserted overlays, or components visible only after interaction. Evaluate the rendered experience and ask whether users can both perceive the information and understand what action is available.
Build a Reusable Accessible Color System
Rather than testing hundreds of arbitrary color combinations each time, define a limited set of design tokens for body text, muted text, headings, links, surfaces, borders, status messages, and focus indicators. Document which foreground colors are approved on which backgrounds. A token called “muted text” should still meet the proper requirement where it is used as functional text; “muted” is a visual role, not an accessibility exemption.
When building a palette from imagery, the Image Color Palette Extractor can support early color selection, but extracted colors still need contrast testing. The Form Label Checker and ARIA Attribute Checker address related accessibility concerns that color ratios alone cannot establish.
The goal is not to turn every website black and white. A practical palette can keep strong branding, differentiated states, and readable content when color pairs are selected with their intended context in mind. Keep the tested pairs documented so future redesigns, new components, and content updates do not quietly reintroduce avoidable contrast problems.
