Why is "high-grade grey" often hard to see clearly? UI color matching should not be based solely on what looks comfortable on the monitor; it is necessary to check the actual contrast

Many interfaces look very "light" on designers' high-brightness Retina screens, but when switched to ordinary office monitors, outdoor mobile phones or users with deteriorating eyesight, secondary text is almost gone. The comparison requirements of WCAG do not restrict aesthetics but set a minimum safety line for the readability of information.

01 4.5:1 for regular text and 3:1 for large text are the base lines of WCAG 2.2AA

The current WCAG 2.2 Understanding document of W3C stipulates that the ratio of ordinary text to background should be at least 4.5:1. For large-sized text, the ratio should be at least 3:1.

These are thresholds and should not be rounded off. 4.49:1 do not pass at 4.5:1 just because it is "about right".

02 The judgment for large text is not "It looks quite large".

WCAG explains that medium and large font sizes typically correspond to 18pt normal or 14pt bold, approximately equivalent to CSS size references of 24px and 18.5px respectively.

When the font is very thin, even if it meets the mathematical standards, it may be more difficult to read in actual rendering. Therefore, it is best to leave some margin in the design.

03 The text that appears in Placeholder and Hover/Focus also needs to be readable

Some designs make the input prompts extremely light gray, considering them merely supplementary information. The W3C clearly states that the text that appears in placeholders and on Hover/Focus also falls within the scope of contrast requirements.

If the input format is very important, the unique description should not be placed in a low-contrast Placeholder either.

04 The brand color is not natural and is suitable as the text color

Bright yellow and fluorescent green stand out as large brand blocks on a white background, but they may not be suitable for small-sized links and button text.

The design system can establish dedicated tokens such as on-brand and text-link for Brand colors instead of directly using brand-500 in all scenarios.

05 Text on images and gradients should be checked for the worst background area

In a Hero photo, the left side is very dark and the right side is very bright. When the text is moved a few pixels, the contrast is completely different. You can add a stable mask, a solid color text container, or limit the safe area of the image.

Don't rely on "this sample picture just shows clearly", because the next picture of CMS may be completely different.

06 The disabled state is an exception, but it cannot be made incomprehensible because of this

WCAG has a contrast exception for the inactive UI component, but users still need to understand the existence of the function and why it is unavailable.

Best practices should not merely pursue the minimum compliance. Too shallow "Disabled" text may make users with low vision not even aware of the existence of the option.

07 Do not distinguish errors, states, and charts merely by color

Red and green represent ups and downs, and green/gray represent selected/not selected. Users may not have enough color vision differences.

Combined with ICONS, labels, shapes, arrows and text, it not only enhances accessibility but also enables all users to understand more quickly in complex environments.

08 Place the comparison check in the Token and component stage instead of scanning the page before going live

If text-secondary itself does not meet the standards, dozens of pages will repeat the problem. The design system should be pre-verified at the color combination layer.

Automatic scanning before going online can only detect some technical issues. Only by establishing a secure combination during the design stage can the repair cost be truly reduced.

09 The design system should move the contrast check forward to the Token layer

If designers are asked to check the gray text and background separately for each page, errors will keep repeating. A more effective approach is to pre-validate common combinations for semantic tokens such as text-primary, text-secondary, surface, border, and interactive.

In this way, when the brand changes its skin, it can also conduct concentrated tests instead of waiting until dozens of pages are completed and then finding that the auxiliary text does not meet the overall standards on the new background.

10 True contrast is also affected by transparency, image and state overlay

The hexadecimal values of solid colors in the design draft may meet the standards, but after implementation, the text will have 60% opacity, the background will have gradients or images, and the final contrast will change. Hover, Disabled, Overlay and dark mode also need to be checked separately.

Accessibility acceptance should be based on the final rendering state rather than just looking at two color values in the design Token table.

Frequently Asked Questions

What is the minimum contrast for ordinary text in WCAG AA?

4.5:1 The minimum ratio for large-sized text is 3:1.

Must the Logo also reach 4.5:1?

WCAG has exceptions for text used as logos or brand names, but usability should still be considered if the Logo also serves as an interactive control.

Can the disabled button be used for low contrast?

There are exceptions to the norms, but the design should still remain identifiable and explain the unavailable state.

Can the design tool calculate 4.49 and then set it to 4.5?

No. The W3C clearly states that the threshold cannot be satisfied by rounding.

Is black always the most readable text?

It doesn't necessarily have to be pure black. The key is to have sufficient contrast with the background and take into account the long-term reading comfort.