# Color Contrast Checks Before Release: Text, States, and Real Screens

Traditional Chinese version: [https://accesserty.com/ai/guides/color-contrast-checks-before-release.md](https://accesserty.com/ai/guides/color-contrast-checks-before-release.md)

Page version: [https://accesserty.com/en/guides/color-contrast-checks-before-release/](https://accesserty.com/en/guides/color-contrast-checks-before-release/)

Last updated: 2026-09-30

Color contrast is not only about a brand palette. Before release, check text, links, errors, focus indicators, button states, icons, and component boundaries in real screens.

## Summary

- Review text, focus, errors, and selection on real pages. Genuinely inactive controls have contrast exceptions; do not judge them as though they were operable.
- Automated scans can catch some text contrast issues, but icons, borders, focus indicators, image backgrounds, and interaction states still need human confirmation.
- DevCheck can help with axe scans and visual simulations on the current page; it is not a dedicated color-picking or contrast-ratio calculator.

## Start from real states, not only the design palette

Many contrast problems do not appear in the brand palette. They appear in the flow: a form error turns red, a button is hovered, a field receives focus, a link sits on an image or card background, a component becomes disabled, or the interface switches between dark and light modes.

Before release, the practical question is not only whether two color values pass a ratio. It is whether people can read the text, identify the component, understand the error, and find the focused element in the current screen state.

## What should be checked together?

WCAG 2.2 includes Contrast (Minimum) for text and images of text, Non-text Contrast for components and meaningful graphics, and Use of Color so information is not conveyed by color alone. That makes contrast review broader than one text-ratio check.

- Text and backgrounds: body text, helper text, placeholders, and text shown on hover or focus.
- Links and interactive text: links should not rely only on color when they need to be distinguished from surrounding text.
- Components and states: buttons, inputs, checkboxes, radios, switches, selected, error, and focus states.
- Icons and boundaries: icons, control borders, focus rings, and meaningful chart lines or regions.
- Background changes: image backgrounds, gradients, cards, dark mode, light mode, and brand hero sections.

## Choose the applicable rule before measuring

WCAG 2.2 AA 1.4.3 requires at least 4.5:1 for ordinary text and 3:1 for large text: 18 pt (24 CSS px), or 14 pt bold (about 18.67 CSS px). For East Asian fonts, check the equivalent size in the large-text definition. Helper text, placeholders, and errors are not automatically exempt. Do not round a sub-threshold ratio up to a pass.

The 3:1 rule in 1.4.11 applies to visual information needed to identify controls, states, or meaningful graphics against adjacent colors, not every decorative line. Browser-native controls whose appearance the author has not modified have an exception.

Genuinely inactive controls have exceptions in both criteria; gray styling alone does not make a control inactive. Keeping its purpose and reason for being unavailable understandable is still useful, but that usability advice is not grounds for automatically recording a pale disabled button as a contrast failure.

## A text example you can calculate

Suppose ordinary-sized helper text is opaque #777777 on solid #FFFFFF, without images, gradients, or other layers. The calculated ratio is about 4.478:1, below 4.5:1. Changing the text to #666666 gives about 5.742:1. This is a color calculation, not a measurement of this site or a whole-page pass.

In the browser, confirm the applied text color, size, weight, and background before calculating. Transparency, images, and gradients can change the background beneath the text; check the least favorable area the text can occupy rather than one average background color. Do not sample antialiased glyph edges as the CSS text color.

## Apply the measurements to focus, errors, and selection

Focus: navigate to the submit button and inspect the custom focus indicator against adjacent backgrounds, not the focus color against the hover color. Also check that focus is visible and a fixed header does not entirely cover the control. AA criteria 2.4.7 and 2.4.11 differ from AAA 2.4.13, which adds area and same-pixel before/after contrast requirements. A mandatory 2 px outline is not a general AA rule.

Errors: use test data in an authorized environment to trigger a required-field message without sending real orders or emails. Measure the message against its background and check for wording such as “Enter your email address,” not only a border turning red.

Selection: change a checkbox, radio option, or tab and inspect each state against its background. Use check marks, shapes, or clear text to help identify selection, rather than only changing the same symbol from red to green.

## Automation helps, but it does not cover every state

Automated engines such as axe-core can catch some machine-detectable contrast issues, especially text and background combinations in the current DOM state. They may not see every hover state, dynamically opened menu, image background, custom icon meaning, or business state conveyed through color.

A more reliable workflow is to scan for obvious issues first, then have design, QA, and engineering review important states in real screens. When exact ratios matter, use a dedicated color picker or contrast-ratio tool to confirm the values.

## Where DevCheck and UI Kit fit

DevCheck can run axe scans on the current browser page and provide color vision, text spacing, visual field loss, presbyopia, myopia, and cataract simulations for readability review. These are preliminary checking and discussion clues, not a full audit or legal compliance guarantee.

UI Kit CSS variables and component styles give teams a consistent customization surface, but tokens do not automatically guarantee contrast. The actual question is whether the component remains clear with real content, real backgrounds, and real states.

## A practical pre-release sequence

Adding contrast to a release checklist does not need to start as a large process. Begin with a stable sequence for the main task pages.

- Open the main task flow in local development or staging.
- Run an automated scan and fix obvious text contrast issues first.
- Manually switch hover, focus, error, selected, disabled, loading, empty, and dark/light states.
- Check whether links, form errors, focus indicators, icons, borders, and charts rely only on color.
- Record the page, control and state, foreground/background, font size/weight, unrounded ratio, applicable criterion, and decision. Mark unmeasured states as untested, not passed because a scan found nothing. Re-test the same state after changes, including other supported themes and backgrounds.

## Next steps

- [Web accessibility remediation plan](<https://accesserty.com/en/guides/web-accessibility-remediation-plan/>) — Organize next steps by user task, impact scope, owner, repair level, and re-test method.

- [PDF accessibility structure checks](<https://accesserty.com/en/guides/pdf-accessibility-structure-checks/>) — Review language, tags, images, links, forms, bookmarks, and page consistency signals.

## Related pages

- [Accesserty DevCheck](<https://accesserty.com/en/devcheck/>) — Run browser-based checks on local builds, staging pages, authenticated screens, and interactive states.

- [Understand WCAG check results](<https://accesserty.com/en/wcag-compliance-tool/>)

- [Color contrast glossary page](<https://accesserty.com/en/glossary/color-contrast/>)

- [Automated accessibility checks limits guide](<https://accesserty.com/en/guides/automated-accessibility-checks-limits/>)

- [UI Kit](<https://accesserty.com/en/uikit/>)

- [W3C Contrast Minimum](<https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum>)

- [W3C Non-text Contrast](<https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast>)

- [W3C Use of Color](<https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html>)

- [Focus indicators: AA and AAA distinctions](<https://accesserty.com/en/glossary/focus-indicator/>)

- [Web accessibility checker](<https://accesserty.com/en/web-accessibility-checker/>) — Check real pages, authenticated states, and interactive states before release.

- [Accessibility practice and maintenance guides](<https://accesserty.com/en/guides/>) — Browse guides by practical task: public signals, pre-release checks, post-launch maintenance, and standards limits.