Contrast checker for WCAG AA buttons

Button labels that look fine on your calibrated laptop often fail real users. A color contrast checker compares a foreground hex and a background hex and reports the ratio against WCAG AA and AAA thresholds. Toolsy’s contrast checker is that hex-pair tool: paste or pick two colors, read the ratio, fix weak pairs before you ship. It is not the same product as the presentation contrast checker, which reviews whole slide PDFs for tiny type and weak colors in a room. For decks, use the guide Slide contrast and readability before you present. This article focuses on WCAG AA for buttons and UI chrome on the web.

Why button contrast fails in production

Brand palettes start in a slide or a Figma style guide. Mid-gray text on a soft tint passes the “looks elegant” test and fails 4.5:1 for normal text.

Hover and disabled states get less care than the default. A primary button passes; the ghost button on the same row fails. Dark mode reuses light-mode hex values and collapses contrast.

Designers check the default theme on one monitor. QA never re-checks the destructive button, the link-styled control, or the focus ring against the page background.

What WCAG AA asks for on buttons

For text and images of text (WCAG 2.1 success criterion 1.4.3 Contrast Minimum, Level AA), normal text needs about 4.5:1 against its background. Large text (roughly 18pt regular or 14pt bold and above, per the spec’s large-text definition) needs about 3:1.

For non-text UI (1.4.11 Non-text Contrast, Level AA), visual information needed to identify a control or its state needs about 3:1 against adjacent colors. That covers boundaries, focus indicators, and icon-only cues when those cues are required to recognize the control.

A button with a text label must satisfy the text contrast rules for that label. If the only way to see the control is a pale fill or hairline border, that chrome also needs adequate non-text contrast against the page.

Normal text versus large text on the button

Many button labels are under the “large text” threshold even when the font feels big in Figma. When in doubt, aim for 4.5:1 on the label. Do not rely on “large text” 3:1 unless you have measured size and weight against the WCAG definition.

Placeholder-like labels and thin weights make failures more likely. Bold large labels are the ones that sometimes qualify for the lower text threshold.

Non-text contrast for the control itself

Icon-only buttons, unchecked switches, and focus rings fall under non-text contrast when those visuals are required to identify the control or state. Target 3:1 against adjacent colors.

Default, hover, focus, and pressed states each need a pass if custom styling replaced the browser defaults. Inactive controls are exempt from some requirements; do not use “disabled” as a way to ship permanent low-contrast actions.

Hex contrast checker versus slide readability checker

The contrast checker tests two colors you choose and shows a ratio with AA/AAA grades for text sizes. You bring hex values from CSS or a design token file.

The presentation contrast checker accepts a PDF of slides and returns short notes on tiny type, weak color pairs, and clutter for a room or projector. That is a deck readability pass, not a WCAG hex audit of your website buttons.

Product FAQ on the contrast tool states the same split: this tool checks two colors and a ratio; the presentation tool reviews whole slide PDFs. Link the wrong article and you will optimize the wrong workflow. Keep Slide contrast and readability for decks; keep this page for web UI hex pairs.

When to use which Toolsy tool

Use /contrast-checker for CSS variables, button tokens, link colors, and form labels. Use /deck-contrast when you exported a pitch deck and care about projector readability. You can use both in one week for a product launch (site + sales PDF) without treating them as interchangeable.

How to prepare the colors you will test

Copy computed styles from the browser, not only the brand book. Gradients, overlays, and image backgrounds change the effective background behind the label.

Test the label color against the button fill, and the button fill against the page background when the fill is how users spot the control. Two separate measurements beat one optimistic sample.

Include hover and focus. A 4.6:1 default that drops to 2.8:1 on hover still fails users who track the pointer.

Walkthrough in the contrast checker

1. Open the contrast checker.
2. Enter the text (foreground) hex and the background hex, or use the pickers.
3. Read the contrast ratio and the AA/AAA pass or fail for normal and large text.
4. Adjust either color until AA clears for the size you actually ship.
5. Repeat for hover, active, and dark-theme tokens.

The tool runs in the browser and updates as you change either color. It is a quick check, not a full accessibility audit. You still need keyboard tests, names, and semantics elsewhere.

Buttons, links, and ghost styles

Primary filled buttons: check label vs fill. Outline buttons: check label vs page background, and the border vs page if the border is required to see the control. Ghost buttons on photos: sample the average or worst patch behind the label, or add a solid scrim and retest.

Link-styled controls in dense tables fail often because gray-on-gray feels “subtle.” Subtle is not a WCAG exception.

Dark mode pairs

Invert carefully. A light gray on near-black can pass while the same gray on a raised dark surface fails. Retest each surface token. Do not assume light-mode AA implies dark-mode AA.

How to check the result beyond the ratio

Resize the button to the production font size in the browser. Confirm whether “large text” rules actually apply. If not, require 4.5:1.

Tab to the control. Confirm the focus indicator meets non-text contrast against its adjacent background. A glowing brand halo that disappears on white fails people who rely on keyboard focus.

Have someone view the screen in bright light or with OS high-contrast settings. Ratios are the standard; real devices still surprise you.

Limits, privacy, and when not to rely on this alone

The Toolsy contrast checker is free and aimed at pair testing. It does not crawl your site, score WCAG conformance, or replace a professional audit. It does not read slide PDFs; that is /deck-contrast.

Passing AA on one button does not mean the page conforms. Forms, error text, charts, and media need their own passes.

Hex tools assume flat colors. Text on video, busy photography, or heavy gradients needs a different sampling strategy or a solid backing shape.

Frequently asked questions

What is a color contrast checker?

It compares a text color and a background color and shows whether they pass WCAG AA and AAA rules. Toolsy’s contrast checker reports the ratio and pass/fail for normal and large text. You use it before users complain about gray-on-gray buttons. It is a quick check, not a full audit.

How do I use a contrast checker for WCAG AA buttons?

Enter the label hex and the button fill hex. Aim for about 4.5:1 for normal-sized labels under AA. Retest hover and dark mode. If you are checking a slide deck PDF instead, switch to the presentation contrast checker and the slide readability guide.

What contrast ratio do I need for AA?

Normal text needs about 4.5:1. Large text needs about 3:1 under WCAG AA contrast minimum. Non-text UI identification often needs about 3:1 under 1.4.11. When a button label is not clearly “large text,” use 4.5:1. AAA uses higher thresholds if your target requires it.

Is this color contrast checker the same as the presentation contrast checker?

No. This tool checks two colors and a ratio. The presentation tool reviews whole slide PDFs for tiny type and weak colors in a room. The product FAQ states the same distinction. Use slide contrast and readability for decks.

Does a contrast checker work with hex codes?

Yes. Paste hex values or use the color picker. The ratio updates as you change either color. You can pull hex from CSS variables or a design token file. Keep a note of which state (default, hover, focus) each pair represents.

Do button borders need contrast too?

If the border or fill is required to identify the control, treat that visual information under non-text contrast (about 3:1 against adjacent colors). Text labels still need text contrast against their immediate background. Test both when you ship outline or ghost buttons.

Should I test hover and focus states?

Yes. Custom hover colors often drop below AA while the default state passes. Focus indicators need enough contrast to stay visible on both light and dark surfaces. Failures here show up for keyboard and low-vision users first.

Can I use this tool for charts and icons?

You can sample foreground and background hex values from chart series or icon fills. Meaningful graphics also fall under non-text contrast when understanding depends on those visuals. Complex charts may need patterns or labels beyond color alone.

Is a contrast checker enough for WCAG conformance?

No. Contrast is one part of perceivable content. You still need structure, names, keyboard access, and more. Use the checker to fix button tokens early, then continue with broader QA. Do not treat a single AA pass as a certificate.

Does the Toolsy contrast checker upload my colors?

Colors are evaluated in the browser as you edit them. There is no file upload for this tool. That still is not a substitute for your company’s rules about unpublished brand palettes in shared environments. For slide PDFs, /deck-contrast is a separate upload-based workflow with its own limits.

For pitch decks and projectors, continue with Slide contrast and readability before you present. For web buttons and tokens, stay on the contrast checker. When you need to normalize brand hex/RGB values before a contrast pass, use Color converter: HEX, RGB, and HSL.