Build a color palette that stays readable in use
A collection of attractive swatches does not tell you whether a page will be readable. Give each color a job, then check the pairs that appear together. This workflow helps you move from a brand color to usable text, surfaces and controls without treating a single contrast score as a complete accessibility review.
1. Start with roles instead of a long swatch list
Choose a page background, a main text color, a muted text color, an action color and text for the action. Add separate roles for borders and meaningful states only when the interface needs them. This makes it clear which combinations need testing and prevents decorative colors from accidentally becoming unreadable body text.
Use the color converter to keep hexadecimal, RGB and HSL representations consistent. Changing a color’s notation does not change its contrast. HSL can help you adjust a color, but its lightness percentage is not the contrast ratio used by WCAG. Test the actual resulting pair.
--surface: #FFFFFF;
--text: #172033;
--action: #4338CA;
--on-action: #FFFFFF;2. Test the foreground and background together
Enter each pair into the contrast checker. WCAG 2.2 Level AA generally requires at least 4.5:1 for normal text and 3:1 for large text. Large text means at least 18 points, or 14 points when bold—approximately 24 and 18.7 CSS pixels respectively. A label styled like a heading does not qualify merely because it looks prominent.
Check body copy, secondary text, input placeholders and button labels at their actual sizes. Compare the full calculated ratio to the threshold; rounding 4.49 to 4.5 does not make it pass. Treat the threshold as a minimum and leave room for thin fonts and less comfortable viewing conditions.
Further reading: W3C: understanding minimum text contrast
3. Check controls and states separately
The text inside a button and the visual features that identify the button are separate checks. WCAG’s non-text contrast criterion generally requires 3:1 against adjacent colors for visual information needed to identify controls and their states, and for meaningful graphical objects. It does not mean every decorative divider must meet that ratio.
Review default, hover, selected, error and keyboard-focus states. For example, a subtle input border can disappear on its background even though the label is easy to read. Test the visual information users rely on to locate and operate the control.
Further reading: W3C: understanding non-text contrast
4. Account for the entire gradient behind text
Use the gradient generator for a background, then check the colors behind the text across its full area. A passing pair at one end does not establish that every part of a gradient works. Changing screen width can move text over a different portion of the background.
For an easier layout to maintain, put long text on a solid surface and reserve gradients for surrounding decoration. If text must overlap a gradient or image, use a suitable solid or translucent backing and test the resulting composite colors. Recheck mobile layouts and wrapped headings.
5. Keep meaning visible without color alone
Pair an error color with a written message and a clear relationship to the affected field. Give chart series labels or patterns, and make links identifiable without requiring users to distinguish two similar hues. WCAG requires that color is not the only visual way to convey this information.
Record approved foreground/background combinations with your design tokens. Recheck them when colors, opacity or typography change. Color testing covers one part of the experience; keyboard operation, labels, focus behavior and readable content still need their own review.
Further reading: W3C: conveying information beyond color