Web accessibility color contrast ratio compliance checker | ZeroTools

This color contrast checker calculates the contrast ratio between text and background colors for two opaque sRGB solid colors specified by the user.

The comparison targets are the two colors specified in the input fields or the color picker, and it is not an accessibility auditing feature that automatically scans entire web pages.

The input fields strictly require valid opaque hexadecimal notation in 3-digit (#RGB) or 6-digit (#RRGGBB) format, with surrounding whitespace trimmed and character case normalized.

The leading pound sign (#) is required, while 4-digit or 8-digit HEX with alpha channels, CSS color functions like rgb() or hsl(), named color strings, and arbitrary invalid characters are rejected.

When invalid input is detected, calculations are withheld so no contrast ratio, pass or fail badge, or adjusted candidate is generated, and the visual preview defaults to a neutral fallback rather than an unintended measured black.

Direct individual R, G, and B channel inputs remain unsupported.

Each color can also be selected from the color picker. There is a button to swap the text and background colors, allowing you to check the visual appearance with the foreground and background inverted using the same two colors.

Since the contrast ratio itself is calculated from the lighter and darker sides, swapping the two colors does not change the numerical value.

However, the roles of foreground and background will change in the text preview on the screen.

The screen displays the relative luminance, contrast ratio, and the AA/AAA results for normal text and large text across four criteria.

The preview at the bottom is an example display applying the selected two colors to a heading (typically 18px bold to 20px) and normal text (12px to 14px).

Because it does not read CSS or the DOM from an actual site, the user must check the text size, weight, state, and surrounding colors at the usage location and select the appropriate criteria themselves.

Actual font confirmation is necessary, and this preview does not guarantee that 18px bold satisfies the large text conditions.

Success Criterion 1.4.3 "Contrast (Minimum)" in WCAG 2.1 and 2.2 is Level AA. The standard is at least 4.5:1 for normal text and 3:1 for large-scale text.

The higher Success Criterion 1.4.6 "Contrast (Enhanced)" is Level AAA, requiring at least 7:1 for normal text and 4.5:1 for large-scale text.

This tool compares the two input colors against these four thresholds.

There is no independent Level A numerical threshold for the contrast ratio. Level A's 1.4.1 "Use of Color" is a separate success criterion stating that color should not be the only visual means of conveying information.

This tool displays the text contrast for AA and AAA, and does not comprehensively evaluate the three levels of A, AA, and AAA based on a single ratio.

The screen also provides a 3:1 reference display for UI component boundaries and the like. Success Criterion 1.4.11 "Non-text Contrast" is Level AA, requiring at least 3:1 between adjacent colors for visual information necessary to identify UI components or graphical objects needed to understand content.

This does not mean the text inside a button can always be lowered to 3:1; the text itself is subject to the 1.4.3 criteria.

This tool does not analyze which lines of a component are necessary for identification, which colors are adjacent, or how states like normal, hover, focus, selected, and disabled change.

Therefore, the 3:1 section simply displays whether it meets or falls below the reference value, and does not finalize the pass/fail for the entirety of 1.4.11 with just these two colors.

Furthermore, meeting a numerical threshold is not synonymous with actually being readable for every user. Thin typefaces or special fonts may appear faint after anti-aliasing even if they meet the designated color ratio.

Therefore, a passing result alone cannot determine the entire page's overall WCAG compliance or guarantee complete readability for all users.

You should always verify the appearance under actual device and display conditions.

The 8-bit values for red, green, and blue obtained from the HEX are first divided by 255 to normalize them into sRGB components from 0 to 1.

In the current W3C definition, if the normalized component C is 0.04045 or less, C is divided by 12.92; if it is larger, it is linearized using ((C + 0.055) / 1.055) ^ 2.4.

Standard sRGB channel linearization first evaluates a branching threshold of 0.04045 in its electro-optical transfer function. After linearizing each color channel, relative luminance is calculated as the weighted sum of the linearized red, green, and blue components using coefficients of 0.2126, 0.7152, and 0.0722 respectively.

Contrast ratio is then evaluated as (lighter + 0.05) / (darker + 0.05). Although some legacy documentation referenced an earlier 0.03928 threshold, standard 8-bit integer channels map 10/255 to approximately 0.039216 and 11/255 to approximately 0.043137.

Because no discrete 8-bit integer channel values fall between 0.03928 and 0.04045, this mathematical difference never alters the linearization branching path or resulting contrast ratio when evaluating standard opaque #RGB or #RRGGBB hexadecimal inputs.

From the linearized R, G, and B, the relative luminance L is calculated as 0.2126R + 0.7152G + 0.0722B. Relative luminance is 0 for black and 1 for white.

The coefficient for green is the largest because it uses specified luminance coefficients rather than averaging the sRGB components with equal weight.

Letting the relative luminance of the lighter of the two colors be L1 and the darker be L2, the contrast ratio is calculated as (L1 + 0.05) / (L2 + 0.05).

The ratio for identical colors is 1:1, and for black and white it is 21:1. With the initial text color #3b82f6 and background color #ffffff, the ratio is displayed as 3.68:1.

This combination exceeds the 3:1 required for large-scale text AA, but falls short of the 4.5:1 required for normal text AA.

Pass and fail decisions are evaluated against unrounded floating-point contrast ratios using the strict thresholds of 3:1, 4.5:1, and 7:1, whereas the on-screen numeric value is formatted to exactly two decimal places for readable presentation.

As a result, a marginal boundary ratio like 4.498:1 is displayed as 4.50:1 while still being correctly marked as failing the 4.5:1 threshold.

Additionally, the user interface boundaries and icons indicator serves as a 3:1 reference point rather than certifying full WCAG 1.4.11 non-text contrast conformance across complex states.

WCAG defines large-scale text as 18pt or larger, or 14pt or larger if bold, and the equivalent size for CJK characters. The WAI Understanding document explains that 18pt is approximately 24px and 14pt is approximately 18.5px as a CSS conversion guide.

However, these px values should not be treated as absolute boundaries for all typefaces including Japanese; you must consider the equivalent size including the font and language.

The criterion is not "if it's bold, it becomes large-scale regardless of size." For example, small bold text cannot have the large-scale text threshold applied to it as is.

Conversely, text with a normal weight that is sufficiently large falls under the 18pt or larger condition. Please check the font-size and font-weight in your design specifications before selecting the normal or large-scale results.

The large text example in the tool is displayed as typically 18px bold to 20px, and the normal text example is between 12px and 14px.

Since 18px bold is smaller than 14pt (approximately 18.67px), this preview does not serve as proof of meeting the large text passing condition.

This is a simplified reference to observe how the two colors might look. It does not replicate the actual font family, font weight, or OS rendering, so you must confirm readability in your actual destination environment.

In addition, this tool does not analyze web pages by entering a URL, nor does it retrieve the font-size or font-weight of elements.

Displaying the four rows for normal text AA, large text AA, normal text AAA, and large text AAA simultaneously is not an automatically determined result, but to show the selection material by comparing the same two colors against each numerical threshold.

Contrast requirements may also apply to text in images, but this tool does not recognize text areas within an image. When picking colors from an image, consider the changes in the edges of the text and the background, and separately select and input the combinations of colors that are actually touching.

When an input text color fails the 4.5:1 AA or 7:1 AAA criterion against a fixed background, the tool searches for alternative text candidates by holding Hue (H) and Saturation (S) constant while scanning Lightness (L) across 101 discrete integer steps from 0 to 100 inclusive.

While sampled L values are integers, the original color's L can be fractional. Each sampled HSL candidate point is converted to a rounded 8-bit HEX value, and its raw unrounded contrast ratio is re-evaluated and validated against the background.

From the passing candidates, the tool selects the one with the smallest absolute difference between sampled L and original L, rather than measuring integer distance or using perceptually uniform color spaces.

Because each candidate is converted to a rounded 8-bit hexadecimal color and re-tested using its unrounded raw contrast ratio during sampling, the suggested HEX value is already verified to satisfy the target threshold.

Clicking 'Apply' transfers this verified candidate into the text color field, instantly updating the displayed ratio and numeric threshold indicators.

Note that this method only evaluates the lightness difference within the HSL space. It is not determining perceptual proximity using RGB space distance, Lab, OKLab, or color difference ΔE.

Thus, it should be used as a 1% increment lightness candidate with fixed hue and saturation, rather than strictly the "closest color," "optimal color," or "shortest color change."

Depending on the chosen background color, adjusting only the text lightness may be mathematically unable to achieve a 7:1 contrast ratio for normal text AAA across any of the 101 sampled points.

When no candidate meets the required threshold, the tool explicitly indicates that no suggestion is available instead of providing an unverified fallback, signaling that you should adjust the background color or investigate alternative color pairings.

For the AA 4.5:1 requirement, either black or white can reach it within the premise of opaque sRGB. However, it may not necessarily fit your actual brand colors or design requirements.

Do not finalize the candidate as is; adjust it while observing the role of the color, state changes, and the actual text display.

This tool evaluates contrast strictly between two opaque sRGB solid colors defined by valid 3-digit (#RGB) or 6-digit (#RRGGBB) hexadecimal values.

It strictly rejects 8-digit HEX codes, alpha transparency, rgba(), CSS opacity, and functional notations, and it cannot audit gradients, background images, or dynamic interactive pseudo-states.

Furthermore, while the visual preview renders sample text using an h4 heading at 18px bold (md: 20px bold) and body text at 12px normal (md: 14px normal), this sample preview and font weight styling provide visual guidance only and do not constitute a complete WCAG accessibility certification.

The h4 element cannot be assumed to qualify automatically as large-scale text under WCAG standards. Full compliance verification requires testing real-world typography, responsive layouts, zoom, and final composited displays.

With gradients, photographs, patterns, and background images, the color behind the text varies depending on the position. Entering a single representative color into this tool does not mean all text positions have been evaluated.

Check multiple locations touching the text, and individually consider them, including the combination with the lowest contrast.

There is also no feature to directly analyze color spaces like Display-P3, Lab, LCH, or OKLCH. It does not scan CSS variables, inheritance, pseudo-elements, or hover/focus/selected/disabled states, and it does not perform simulations to replicate the appearance for different color vision types.

You must separately verify issues such as whether information is conveyed solely by color, whether focus indicators are visible, and whether boundaries for each state can be distinguished.

The entire WCAG auditing process is not covered here. The HEX processing, relative luminance, ratios, and HSL candidates are calculated as JavaScript on the browser screen.

This explains the processing scope to mean it does not use a dedicated API that sends the two calculation target colors to an external service for analysis.

It does not deny communications for page rendering, ads, access analytics, common features, or browser extensions, nor is it an expression that guarantees the complete offline status or security of the entire site.

This checker is a numerical verification means for considering color schemes. Please confirm by combining numerical standards, actual text, images and transparency, operating states, and clues other than color, and if necessary, conduct a separate accessibility audit targeting the entire page.