Turn Accessible CTA Colors into Reusable Design Tokens
Use a practical process to compare CTA colors, check their surrounding states, and turn reliable choices into reusable design tokens.
turn accessible cta colors into reusable design tokens
Contents
- [Start with the CTA decision](#start-with-the-cta-decision)
- [Build a small action token set](#build-a-small-action-token-set)
- [Check more than the default button](#check-more-than-the-default-button)
- [Document the token handoff](#document-the-token-handoff)
- [Use this in your AI agent](#use-this-in-your-ai-agent)
To turn accessible CTA colors into reusable design tokens, first test each color in its actual button or link context, then assign semantic roles instead of naming tokens only by hue. The goal is a small set of dependable action tokens that work across default, hover, focus, disabled, and text-on-color states.
Start with the CTA decision
Use this order:
- Identify the CTA's job: primary action, secondary action, quiet link, destructive action, or selected state.
- Test the fill against its label, the button against the surrounding surface, and the focus indicator against both.
- Test the same role in every visible state.
- Choose the simplest color family that meets the checks without creating unnecessary near-duplicates.
- Name the result by purpose, not appearance.
For example, action-primary is more useful than green-700 because the role stays understandable if the brand color changes. Keep the raw color value in the token definition, but let components consume the semantic name.
The examples below show a muted green visual direction. The observed list includes dark greens such as #15502e, #14532d, and #233f2a, brighter greens such as #1e6f30 and #2c7a4a, and a lighter green-gray, #799c92. They are useful starting points for comparing tone and hierarchy, but they should not be treated as proven CTA choices without testing them in the intended interface.
Captured pages
Colors
#496c10#15502e#14532d#233f2a#254f1a#1e6f30#295631#556659#4a5a4a#2c7a4a#2a966f#799c92
Build a small action token set
A practical CTA token set might look like this:
The comments matter during the first pass. Replace them with values only after each pair has been checked. If a button uses a gradient, keep the gradient as a component style and define the label, focus ring, and surrounding surface as separate tokens. Do not make one token responsible for every visual relationship.
Use a decision table while reviewing:
| Token role | Test against | State coverage | Keep when |
|---|---|---|---|
| Primary fill | label and page surface | default, hover, focus, pressed | it remains clear and prominent |
| Primary label | every point of the fill | default and disabled | it stays readable across the blend |
| Secondary action | page surface and border | default, hover, focus | it remains distinct without competing |
| Focus indicator | button and nearby surface | keyboard focus | it is easy to locate |
| Disabled action | page surface | disabled | it looks inactive without becoming confusing |
Check more than the default button
A CTA can appear accessible in a static mockup and fail in use. Review white and dark labels where both are plausible. Check text at the smallest size, icons without labels, adjacent buttons, and the space between a button and its background. If a color is used over a gradient or image, inspect the entire area behind the content rather than sampling one point.
Also look at hierarchy. Two buttons can both pass contrast checks yet have insufficient visual separation between primary and secondary actions. Use fill, border, size, position, and spacing together. Color should support the decision, not carry the entire meaning.
When a CTA color changes by state, compare the transition as well as the final color. Hover should be visible without becoming a different action, focus should be unmistakable, and disabled should not be confused with an unavailable page element that still accepts input.
Document the token handoff
For each token, record the semantic name, value, intended text color, surfaces tested, states covered, and any exception. Add a short usage rule, such as "use for the main conversion action on light surfaces" or "do not place small text directly over the gradient." This makes the token reusable without hiding the conditions that made it work.
For a more detailed review, inspect the website color palette feature. A captured page can be compared by color role, frequency, contrast, gradients, borders, and component styles. That helps separate a repeated CTA decision from a color that merely appears in an illustration or background.
Use this in your AI agent
> Review the captured website's CTA colors and turn the reliable choices into semantic design tokens. Identify primary, secondary, quiet, focus, pressed, hover, disabled, label, border, and surrounding-surface roles. Check each role in its actual component context and across visible states, including gradients and nearby text. Return a compact token table with raw values, semantic names, usage rules, tested combinations, and unresolved checks. Do not promote colors from images or decoration into CTA tokens without evidence.
How many CTA color tokens should a small design system start with?
Start with the fewest roles your interface actually needs. For many small systems, that means one primary action family, one secondary action family, a focus treatment, a disabled treatment, and label colors for light and dark fills. Add destructive or selected-state families only when those actions exist and need different meaning.
Avoid creating a token for every shade in a sampled palette. A large list makes it harder to choose consistently and can hide the fact that several values serve the same job. Instead, test a candidate family across buttons, links, cards, and form controls. If one value works for multiple components without losing hierarchy, keep it shared. If the same hue needs different contrast, opacity, or state behavior, split it by role.
Name tokens around use, such as action-primary, action-primary-hover, and focus-ring, rather than green-dark. Keep a small raw palette underneath only if the team needs it for illustration or visual exploration.
How can I hand off CTA tokens without claiming that accessibility is fully solved?
Label the handoff as a tested snapshot with clear boundaries. Include the component size, text size, label color, background or surface, state, and whether the value was checked across a gradient or image. Note any combinations that still need review in code, especially responsive layouts, user-selected themes, focus visibility, and dynamic content.
Use a table with columns for semantic role, raw value, intended use, tested foreground, tested background, states reviewed, and open questions. Add screenshots of representative primary and secondary CTAs so the visual hierarchy remains clear. If a gradient is involved, document the full blend and the content placement rather than only the endpoints.
Avoid phrases such as "accessible by default" unless the complete implementation has been checked. A more accurate note is "passes the listed checks in the reviewed states." This preserves useful evidence while giving developers a concrete list of follow-up tests before release.