Color contrast testing should examine the information people need in the interface they actually use. A palette can contain accessible color pairs while a muted field hint, transparent button, selected chart series, or error message fails in a rendered state. Measuring the brand colors once leaves those questions unanswered.
This guide turns the relevant WCAG 2.2 requirements into a review workflow with a state matrix and an illustrative finding. Use the manual and automated accessibility testing plan to decide what each method can inspect, and preserve results with the accessibility evidence handoff.
Match each contrast question to the right requirement
Contrast (Minimum), SC 1.4.3, is Level AA. Its text threshold is 4.5:1, with 3:1 for large-scale text. The large-scale definition uses at least 18 point, or 14 point bold, rather than the informal label “heading.” Incidental text and text within logotypes have specific exceptions.
Non-text Contrast, SC 1.4.11, is also Level AA. It uses 3:1 against adjacent colors for visual information needed to identify interface components and states, and parts of graphics needed to understand content, subject to its exceptions. It does not require every decorative border to meet a contrast threshold.
Use of Color, SC 1.4.1, is Level A. It addresses information conveyed only through color. A good numerical contrast result does not settle whether someone can distinguish “valid” from “invalid” when the only instruction is to recognize green or red.
Inventory content and interaction states before measuring
Start with the scoped tasks. Identify text, controls, and meaningful graphics used to perform them, including content revealed after an action. Write down the theme and state for each item so a result can be traced back to the interface.
This illustrative matrix is for a fictional appointment service:
| Item | States to inspect | Question to answer |
|---|---|---|
| Appointment search | Default, filled, invalid | Can the user read labels, hints, input, and errors? |
| Filter control | Closed, expanded, selected | Can the user identify the control and its state? |
| Booking button | Default, hover, keyboard focus | Does its relevant information remain perceivable? |
| Availability chart | Initial and selected series | Can the displayed relationships be understood? |
| Booking confirmation | Success and follow-up action | Is the outcome available without interpreting a color alone? |
Repeat relevant states in each supported theme. If a state cannot be reached with the available test account, record the gap and assign the next step. Do not inherit a default-state result for a state that was never inspected.
Measure the rendered foreground and background
Select the actual text or meaningful indicator and determine the colors that form its rendered presentation. A CSS token can be a starting point, but transparency, overlays, gradients, images, and theme rules can change the background behind it.
Use a contrast tool that reports the color pair and calculated ratio. Keep those values with the component and state. For text, retain the font size and weight that explain whether the large-scale threshold applies. If the background varies, inspect the relevant locations rather than selecting a convenient sample elsewhere on the page.
Avoid sampling the blended edge of a text glyph as though it were the intended foreground color. WAI's Contrast (Minimum) explanation discusses anti-aliasing and threshold interpretation. When the intended colors are uncertain, document that uncertainty and investigate the rendered styles instead of reporting an unexplained ratio from a screenshot.
Inspect indicators without requiring every outline to pass
For a control, identify which visible information is necessary to recognize it and its current state. Then measure that information against the adjacent colors. A control may be recognizable through a sufficiently contrasted icon or label without relying on its decorative outline.
Check selected, checked, expanded, and focused states where they exist. Record the necessary indicator and the colors involved. A checklist entry such as “all borders pass” can both miss a meaningful low-contrast indicator and create findings for outlines that do not convey needed information.
The non-text criterion includes exceptions for inactive components and unmodified browser-controlled appearance. Explain an exception decision in context. Do not treat a disabled control's exception as approval for an unreadable error next to it, or assume that an author-styled control is entirely browser-controlled.
Look for information that depends on recognizing a color
Ask what each use of color communicates. A red border can indicate a form error, a green dot can indicate availability, and chart colors can distinguish categories. Inspect whether the same information has another usable visual cue.
For the fictional booking service, “Available” and “Unavailable” text can make status clear without asking a person to identify a dot's hue. An error message can explain the problem rather than relying on a red field. Chart labels or distinguishable patterns can support comparisons between categories.
These are implementation examples, not a requirement to adopt a particular icon or style. Inspect the programmatic information separately: adding a visual word beside a colored dot does not by itself establish that assistive technology receives the relationship correctly. Use the form guide and the screen reader testing guide for those interactions.
Verify tool findings and preserve exact measurements
Automated checks can help locate text contrast concerns in states they can inspect. Review each result in the relevant interface, especially when the tool cannot determine a background, the text changes state, or the report asks for manual review.
Consider a worked example using regular-sized text in #777777 on a solid #ffffff background. Its calculated contrast ratio is approximately 4.478:1, below the 4.5:1 text threshold. Rounding that number to one decimal place would misleadingly display 4.5:1. WAI explains that threshold comparisons must not round a failing result into a pass.
An illustrative finding should name the affected hint, its state, the colors, size and weight, measured ratio, applicable threshold, and effect on reading the instruction. State that it is an example, and retain enough detail for another reviewer to repeat the measurement. A bare “contrast failed” screenshot leaves the remediation team to rediscover those details.
Retest shared styles and preserve the release record
If the correction changes a shared color token, revisit the components and states that use it. Increasing contrast for one label can alter a selected control, dark-theme surface, or chart elsewhere. Use the matrix to identify the affected checks instead of assuming that a token change resolves every occurrence.
Keep the earlier measurement and add the retest result against the released version. Record which instances were checked and which remain outstanding. The accessibility regression testing guide explains how to connect a change with owned follow-up work.
OnChange's preserved HTML, styles, and screenshots can help investigate changes in presentation. They support the review record; a visual difference alone does not determine whether the current colors meet a requirement. Confirm the relevant presentation and state when making that decision.
Sources and the boundaries of this checklist
The three W3C Understanding documents linked above were checked on 6 October 2026. They explain the WCAG 2.2 criteria and their exceptions. The appointment matrix, review sequence, and worked finding are OnChange's practical guidance. This checklist supports color and contrast evaluation within an agreed scope; it does not establish the accessibility of an entire website.