How to analyze accessible CTA colors on a live website

Contents

• [Start with the CTA states](#start-with-the-cta-states)
• [A quick contrast workflow](#a-quick-contrast-workflow)
• [How to improve a failing CTA](#how-to-improve-a-failing-cta)
• [A reusable review checklist](#a-reusable-review-checklist)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

To analyze accessible CTA colors on a live website, compare each call-to-action color with its text, surrounding background, hover state, focus state, disabled state, and nearby content. Do not judge accessibility from a palette alone: the same green can work on white, fail on a tinted surface, and become unclear when used for both primary and secondary actions.

Start with the CTA states

Make a small inventory before choosing replacements:

• primary buttons, such as sign-up or purchase actions
• secondary buttons and outline buttons
• text links that perform an important action
• navigation CTAs and promotional banners
• hover, pressed, focus, loading, and disabled states
• dark-mode or alternate-surface versions

For every item, record the foreground color, background color, border color, text size and weight, and whether an icon carries meaning. Capture the normal and interactive states separately. A button that passes in its default state can become difficult to distinguish when hover darkens the background or when focus is shown only by a subtle color change.

The captured examples below include a Pangram AI Detector reference and a muted green palette containing values such as #496c10, #15502e, #14532d, #233f2a, and #2c7a4a. Use these as comparison material, not as a ready-made accessible token set. Open the reference and check how the green direction is paired with text, surfaces, borders, and surrounding whitespace.

A quick contrast workflow

For each CTA, run this sequence:

1. Identify the role. Decide whether the color signals the main action, a secondary action, success, a warning, or a decorative accent.
2. Check text contrast. Test the button label against its fill. Large text may have different requirements than regular-sized text, so record the actual size and weight.
3. Check component boundaries. Test the button edge against the page surface, especially for outline buttons and pale fills.
4. Check focus visibility. Make sure keyboard focus is visible against both the component and the surrounding page. A color shift alone may not be enough if it is hard to notice.
5. Check non-color cues. Confirm that a user can understand the action from its label, icon, shape, or state change without depending only on red, green, or another hue.
6. Repeat on every surface. Test cards, banners, footers, dark backgrounds, tinted sections, and mobile layouts.

Keep the results in a table with columns for role, normal state, hover, focus, text contrast, boundary contrast, and recommended change. This makes it easier to fix the system instead of patching one button at a time.

How to improve a failing CTA

If the label has weak contrast, first adjust the text or fill while preserving the action's role. If the boundary disappears, strengthen the border or add a clearer shape difference. If focus is unclear, add a visible outline or offset ring rather than relying on a small hue change. If a pale green is important to the brand, reserve it for backgrounds or supporting surfaces and use a darker companion for the actionable control.

Do not make every CTA the darkest color. A useful hierarchy usually needs one clear primary action, a quieter secondary action, and supporting links that remain recognizable without competing with the primary button. Test the hierarchy in grayscale as a quick check for overreliance on hue.

A reusable review checklist

Before approving the page, check normal and interactive states, light and dark surfaces, text and boundary contrast, keyboard focus, touch target clarity, disabled styling, icon meaning, and grayscale hierarchy. Save the result as named roles such as cta-primary, cta-primary-hover, and focus-ring, with a short note explaining where each role is safe to use.

A palette inspection can help you spot repeated colors and likely roles, while a page inspection tells you where those colors actually appear. Use both before changing tokens.

Use this in your AI agent

> Analyze the captured website's CTA colors by role and state. List each primary, secondary, link, outline, hover, pressed, focus, loading, and disabled treatment you can observe. For every treatment, report foreground, background, border, surrounding surface, and any non-color cue. Flag combinations that need a contrast check, propose accessible role-based replacements, and keep observed colors separate from recommendations. Finish with a compact token table and a manual keyboard and grayscale review checklist.

Install Fudge for your AI agent

Keep the branded green where it has room to work, but do not force one shade to serve every role. Use the lighter green for a background, illustration, badge, or low-emphasis surface, then pair it with a darker green for the button fill or text. Preserve the hue direction while changing lightness and saturation enough to create a readable pair.

You can also keep the green in the border, icon, or focus treatment while using a more contrasting fill. Make sure the action remains clear from its label and shape, not only from the color. For a primary CTA, test the label against the fill and the component edge against the page background. For an outline CTA, test both the text and border because either one may disappear.

Document the decision as roles rather than one universal brand token. For example, define separate values for primary fill, primary text, outline border, soft surface, hover, and focus ring. Then review the full set together in light mode, dark mode, keyboard focus, and grayscale.

Use this prompt:

> Review the captured website's calls to action in a fixed order. First inventory primary buttons, secondary buttons, outline buttons, important links, banners, and their hover, pressed, focus, loading, and disabled states. Next identify the foreground, fill, border, surrounding surface, text size, weight, icon use, and visible non-color cues for each state. Then group repeated colors into proposed roles, but do not assume a color is safe until its actual placement is checked. Mark every result as observed, needs manual contrast verification, or recommended change. Compare light, dark, tinted, card, footer, and mobile surfaces when available. Return a table of issues with the smallest practical fix, followed by a token proposal and a keyboard-focus, grayscale, and label-clarity checklist.

After the review, manually test the recommendations in the browser with keyboard navigation and the real page copy. Keep any uncertain result visible instead of silently treating it as approved.

Related questions

• Analyze a Dark Mode Color Palette on a Live Website
• Turn a Website Gradient Palette Into Reusable Design Tokens
• Analyze Text and Background Contrast on a Live Website
• Turn Text and Background Contrast Into Reusable Design Tokens