Extract Accessible CTA Colors from a URL

Contents

• [Use a simple CTA color check](#use-a-simple-cta-color-check)
• [Check the combinations, not the palette](#check-the-combinations-not-the-palette)
• [Build a safer set of roles](#build-a-safer-set-of-roles)
• [A quick handoff checklist](#a-quick-handoff-checklist)
• [Use this in your AI agent](#use-this-in-your-ai-agent)

To extract accessible CTA colors from a URL, first capture or open the page, identify the button background and text colors, then check their contrast in every important state. Treat the result as a small role-based palette, not just a list of hex codes.

Use a simple CTA color check

For each primary call to action, record:

1. The button background color.
2. The label color.
3. The border or outline color, if it carries meaning.
4. The hover, focus, pressed, disabled, and visited states.
5. The nearby surface color, especially when the button is outlined or transparent.

Then compare the foreground and background as pairs. A color can look strong in a palette but fail when used behind small text. A pale button may also need a visible border if its edge is difficult to distinguish from the surrounding surface.

The practical output should look like this:

• Primary CTA: dark green background with white label
• Secondary CTA: light surface with dark green label and visible border
• Focus state: same CTA colors plus a clearly visible focus ring
• Disabled state: lower emphasis, but still distinguishable from the page background

This makes it easier to fix the component rather than arguing about individual swatches.

Open the example below and compare the first screen before borrowing a pattern. The captured reference uses a muted green direction, with examples including #496c10, #15502e, #14532d, #233f2a, #254f1a, and #1e6f30. Those colors are useful starting points for exploration, not proof that a particular button passes every contrast check.

Check the combinations, not the palette

A useful review table has four columns: element, foreground, background, and result. For example:

Do not assume that a darker color always solves the problem. A change to the surface behind the button can alter the result without changing the button itself. Also check text size and weight, because small labels need more separation than large display text.

For a first pass, look for repeated CTA colors across the page. If the same green appears in headings, links, icons, and buttons, separate those roles before changing anything. A link color that works on a white surface may not work as a button fill with white text.

Build a safer set of roles

Keep the extracted values organized into roles such as cta-primary, cta-primary-text, cta-secondary, cta-secondary-text, cta-focus, and cta-disabled. Add light and dark surface variants when the site supports both themes.

For every role, save the intended use beside the hex value. For example, #15502e might be tested as a filled CTA background, while #799c92 may be better treated as a supporting or disabled color until its combinations are checked. Do not promote a color into a button role solely because it appears frequently.

Review the CTA at its actual size and placement. Contrast checks are strongest when paired with a visual inspection of the button label, border, focus indicator, and surrounding whitespace. If the result will guide a redesign, keep the original screenshot or capture beside the extracted values so the decision remains tied to the observed component.

A quick handoff checklist

Before shipping the palette, confirm that:

• Every CTA state has a foreground and background pair.
• Primary and secondary buttons remain distinct without relying on color alone.
• Focus is visible against both the button and the page surface.
• Disabled controls are still recognizable as controls.
• Dark and light surfaces have been checked separately.
• The final values are labeled by role and component, not only by hex code.

Use this in your AI agent

> Extract the CTA color roles from this URL. For each primary, secondary, outline, icon-only, hover, focus, pressed, and disabled state, list the observed foreground, background, border, and focus-ring colors. Compare the combinations for contrast, flag uncertain pairs, and return a compact role-based palette with recommended fixes. Do not treat frequent colors as accessible until their actual text and surface combinations are checked.

Install Fudge for your AI agent to inspect a captured page and compare the colors in their actual component context.

Group buttons by purpose first, then check each purpose across its states. A primary button usually has a filled background, a secondary button may use a lighter surface or border, and a text action may depend on underline, spacing, or another non-color cue.

Create one row per style and state. Record the label color, fill color, border, focus ring, and the surface behind it. Check the normal, hover, focus, pressed, and disabled versions rather than testing only the default screenshot. If the same button changes color on hover, both combinations need review.

Also check whether two adjacent buttons can be told apart without color alone. For example, a primary action can use a filled shape while a secondary action uses an outline, so the hierarchy survives grayscale viewing. For icon-only buttons, check the icon against its background and confirm that the control has a visible label or equivalent name.

When a style fails, change the role pair first. Avoid changing one shared green everywhere, because that can fix a CTA while making links, headings, or status indicators harder to read.

Start with a capture of the page and create a short inventory of CTA components. For each one, save the observed values under names such as button-primary-bg, button-primary-text, button-secondary-border, and button-focus-ring. Include the surface context in your notes, such as white, tinted, or dark background.

Next, reduce duplicates only after checking their use. Two hex values that look close may serve different roles, while one repeated value may need separate tokens because it appears on different surfaces. Keep uncertain values marked for review instead of forcing them into the final system.

Then define the approved combinations. A token is useful when its name explains where it belongs and its pairing has been checked. For example, a background token should be documented with its intended text token, not handed off as an isolated swatch.

Finally, test the tokens in the real button sizes and states. Review keyboard focus, hover, pressed, disabled, light mode, and dark mode where relevant. Keep the extracted palette as evidence of what was observed, but treat the finished token set as a design decision that still needs product and accessibility review.

Related questions

• Extract a Dark Mode Color Palette from a URL
• Check a Website Gradient Palette Inside Claude Code
• Extract Text and Background Contrast from a URL
• Check Website Color Roles Inside Claude Code