Accessibility is not a command to remove color. It is a reason to give each color a clear role and test the combinations people actually need to read.
Design roles before individual swatches
A palette becomes easier to test when every color has a job: page background, surface, primary text, secondary text, border, action, success, warning, and danger.
Starting from roles prevents a common failure where attractive swatches are created first and forced into interface uses later.
Test actual foreground and background pairs
A color does not pass or fail accessibility on its own. Contrast is a relationship between a foreground and a background, at a particular text size and weight.
Test the combinations that ship: body text on page backgrounds, labels on controls, links inside content, button text, disabled states, and validation messages.
Do not use color as the only signal
Status colors should be supported by text, icons, patterns, or shape changes. A red border alone is easy to miss and may be indistinguishable for some users.
- Pair error colors with a message and an icon.
- Underline links inside paragraphs.
- Use labels for chart series where possible.
- Keep focus states visible in every theme.
Preserve character through hierarchy
The accessible option is not always the darkest or most muted one. Strong accent colors can remain expressive when text, borders, and surrounding surfaces carry the readability work.
Use saturated color for selected states, swatches, charts, and large graphical areas. Use tested neutral pairs for longer reading.