EyeCaptain
    WCAG Contrast Ratio for Buttons: Accessibility That Converts

    WCAG Contrast Ratio for Buttons: Accessibility That Converts

    Learn the WCAG contrast ratio for buttons, the 2.2 target size rule, focus states and form labels, and how fixing them helps every visitor convert.

    Dimitris Andreadakis

    8 min read
    177 views
    WCAG contrast ratio buttonsWCAG 2.2 target sizeaccessible button designfocus state accessibilityaccessible form labels

    Under WCAG 2.2 level AA, button text needs a contrast ratio of at least 4.5:1 against the button color, or 3:1 if the text is large. The button's shape needs 3:1 against the page. Targets should be at least 24 by 24 CSS pixels, with visible focus states and real form labels.

    These rules describe a page that is easy to use: buttons you can read in sunlight, tap without missing and find with a keyboard. Every visitor benefits. This guide covers the four areas that most often hurt conversion, with the exact criteria and fixes.

    What contrast ratio does WCAG 2.2 require for buttons?

    WCAG 2.2 sets two contrast rules for buttons: one for the label text, one for the button shape.

    • Text on the button (Success Criterion 1.4.3, AA): 4.5:1 for normal text. Large text needs 3:1. WCAG defines large as at least 18 point regular or 14 point bold, which is roughly 24 CSS pixels regular or 18.66 pixels bold.
    • Button boundary and states (Success Criterion 1.4.11, AA): any visual information needed to identify the control, such as a filled button's color against the page or an outline button's border, needs at least 3:1 against adjacent colors. This also applies to focus indicators and to states like "selected".

    Disabled buttons are exempt from these minimums. That exemption is often abused: a pale, low-contrast "Continue" button that is actually active looks disabled to shoppers, and they wait for something to happen.

    Which button color combinations usually fail?

    The combinations that fail most often are white text on bright, light brand colors. White on a vivid orange, yellow, lime green, light teal or sky blue frequently lands under 4.5:1, even though the button looks bold on a designer's calibrated monitor. Other common failures:

    • Ghost buttons with a thin pale gray border on white.
    • Gray secondary buttons with gray text.
    • Text placed on a gradient, where one end passes and the other fails.
    • Buttons placed over hero photos, where contrast changes with every crop and screen size.
    • Placeholder text in form fields using the browser's default light gray.

    The fix is rarely a full rebrand. Darken the button fill a few steps, switch the label to a dark color, or keep the brand color for the outline and use a darker shade for the fill. Check every change with a contrast checker such as the WebAIM Contrast Checker or the contrast panel in your browser's developer tools. Which color to choose is a separate question, covered in our color psychology guide.

    EyeCaptain
    Contrast depends on the text size. WCAG AA minimum text-contrast thresholds.

    How big should buttons and touch targets be?

    WCAG 2.2 added Success Criterion 2.5.8, Target Size (Minimum), at level AA: interactive targets must be at least 24 by 24 CSS pixels, unless they have enough spacing around them or meet one of a few listed exceptions, such as links inside a sentence. The stricter AAA criterion 2.5.5 asks for 44 by 44 pixels.

    Platform guidelines go further than the AA minimum. Apple's Human Interface Guidelines recommend at least 44 by 44 points for tap targets, and Google's Material Design recommends 48 by 48 density-independent pixels. For a primary call to action, treat those as the floor, not the goal. The elements that most often fall short are:

    • Quantity plus and minus steppers on product and cart pages.
    • Close icons on popups and drawers.
    • Color and size swatches.
    • Small text links like "Apply coupon" or "Edit address".

    A useful trick: the visible element can stay small if the clickable area is larger. Padding on a link or an invisible hit area around an icon counts. Placement matters too, and our post on thumb zone design covers where to put targets on mobile.

    What makes a good focus state?

    A good focus state is a clearly visible outline or change that shows exactly which element the keyboard is on, with at least 3:1 contrast against its surroundings. Keyboard users include people with motor impairments and anyone filling forms with the Tab key.

    Three WCAG 2.2 criteria apply:

    • 2.4.7 Focus Visible (AA): there must be a visible focus indicator. The most common violation is a global CSS rule that removes outlines for looks.
    • 2.4.11 Focus Not Obscured, Minimum (AA, new in 2.2): the focused element must not be fully hidden by sticky headers, cookie banners or chat widgets.
    • 2.4.13 Focus Appearance (AAA, new in 2.2): sets size and contrast rules for the indicator itself. Not required for AA, but a sound target.

    A two-pixel solid outline offset from the button, in a color that contrasts with both the button and the page, satisfies most designs. Use the CSS :focus-visible selector to show it for keyboard users without showing it on every mouse click.

    EyeCaptain
    A clear label and visible focus. Keep a visible keyboard focus ring. Use a generous primary action target. Name errors in…

    Why do form labels matter for conversions?

    Every form field needs a visible label that stays on screen and is connected to the field in code. WCAG 3.3.2, Labels or Instructions (level A), requires labels or instructions when content needs user input, and 1.3.1 requires the relationship to be programmatically available, usually with a label element tied to the input.

    The common shortcut is using placeholder text as the only label. Once the shopper starts typing, the label disappears. On a long checkout form they forget what a field wanted. Floating labels that shrink above the field are a reasonable middle ground if the shrunken label still meets contrast.

    EyeCaptainEyeCaptain
    88%
    Conversions Booster

    UX bugs are silently killing your revenue

    88% of users never come back after a bad experience. Our AI detects CTA hierarchy issues, mobile gaps, and cognitive overload patterns.

    Mobile UX gaps

    Errors follow the same logic. WCAG 3.3.1 requires errors to be identified and described in text, not only by turning a border red. For wording that helps people fix the error, see our guide to form microcopy.

    How do you audit a page for these issues?

    You can check the four areas on one page in about 30 minutes with free tools:

    1. List the conversion path. Write down every interactive element a buyer needs: primary CTA, variant selectors, quantity, form fields, checkout button.
    2. Check text contrast. Sample each button's text and fill color and run them through a contrast checker. Note anything under 4.5:1, or under 3:1 for large text.
    3. Check boundary contrast. For outline buttons, inputs and checkboxes, check the border against the background for 3:1.
    4. Measure targets. In developer tools, inspect each small control on a mobile viewport and note anything under 24 by 24 pixels, and primary actions under 44 by 44.
    5. Tab through the page. Unplug the mouse. Can you see focus at every step? Does anything disappear behind a sticky bar?
    6. Fill the form. Type in every field and submit with errors. Do labels stay visible? Are errors described in words?
    7. Run an automated scan. Lighthouse or axe catch many, but not all, contrast and label issues.
    IssueWCAG 2.2 criterionAA requirementQuick fix
    Button text hard to read1.4.3 Contrast (Minimum)4.5:1, or 3:1 for large textDarken fill or switch label color
    Outline button blends into page1.4.11 Non-text Contrast3:1 for boundaries and statesThicker, darker border or filled style
    Tiny steppers and close icons2.5.8 Target Size (Minimum)24 by 24 CSS px or enough spacingAdd padding to enlarge hit area
    No visible keyboard focus2.4.7 Focus VisibleVisible indicatorRestore outline with :focus-visible
    Focus hidden by sticky bar2.4.11 Focus Not ObscuredNot fully hiddenAdd scroll padding equal to bar height
    Placeholder used as label3.3.2 Labels or InstructionsLabel or instructions presentPersistent visible label element
    EyeCaptain
    Check more than the button color. Keep the next step usable across input methods.

    What does this look like on a real store?

    Consider a hypothetical skincare store with a mint green brand color. Its "Add to bag" button is mint with white text, which fails 4.5:1. The quantity stepper uses 18 pixel icons. The newsletter popup's close "x" is a 16 pixel glyph in light gray. The checkout uses placeholders as labels, and a sticky "Free shipping over $50" bar covers the focused field as shoppers tab down.

    The fixes keep the brand intact: a deep green fill for the button with white text, mint kept for accents. Stepper buttons get padding to reach 44 by 44. The close icon gets a larger hit area and darker color. Checkout fields get persistent labels, and the page gets scroll padding so focused fields clear the sticky bar. Each change helps a shopper on a phone in bright light as much as a screen reader user.

    Key takeaways

    • Button text needs 4.5:1 contrast at WCAG 2.2 AA, or 3:1 for large text, and button boundaries need 3:1.
    • WCAG 2.2 AA requires targets of at least 24 by 24 CSS pixels; aim for 44 by 44 on primary actions.
    • Never remove focus outlines without a visible replacement, and keep sticky elements from hiding focus.
    • Use persistent labels, not placeholders, and describe errors in words.

    Contrast and competing elements are measurable, so they are easy to check per page. A free CRO audit on EyeCaptain measures CTA contrast and visual weight on desktop and mobile for one URL, and our CRO checklist lists the wider checks.

    EyeCaptain
    Make the action usable. Review keyboard, touch and text, not only the color.

    Frequently asked questions

    Is a 3:1 contrast ratio enough for button text?

    Only if the text counts as large under WCAG: at least 18 point regular or 14 point bold, roughly 24 or 18.66 CSS pixels. Most button labels are 14 to 18 pixels, so they need 4.5:1. The 3:1 ratio does apply to the button's shape against the page background under Success Criterion 1.4.11.

    Do disabled buttons need to meet contrast requirements?

    No. WCAG exempts inactive user interface components from the contrast minimums. The risk is the opposite problem: if an active button is pale, people assume it is disabled. Make sure disabled and active states look clearly different, and consider explaining why a button is disabled, such as "Select a size to continue".

    Does WCAG 2.2 require 44 by 44 pixel buttons?

    Not at level AA. WCAG 2.2 AA requires 24 by 24 CSS pixels, or enough spacing around smaller targets, under Success Criterion 2.5.8. The 44 by 44 size is the AAA criterion 2.5.5 and matches Apple's recommendation. For primary actions on mobile, 44 pixels or more is a sensible design standard.

    Can an accessibility overlay widget fix these problems?

    Overlay widgets cannot reliably fix contrast, target size, focus or labeling problems in your underlying code, and many accessibility practitioners advise against relying on them. The durable fix is changing the CSS and HTML: button colors, padding, focus styles and label elements. These are usually small edits in your theme or design system.

    How do I check contrast on a button over an image?

    Sample the lightest and darkest parts of the image directly behind the text and check both against the text color. If either fails, add a solid or semi-opaque background behind the button or text. Check again at mobile widths, because responsive cropping can move a different part of the image behind the button.

    Enjoyed this article?

    One short email a week with practical CRO and UX tips

    No spam. Unsubscribe anytime.

    Find what stops your visitors from converting

    EyeCaptain is an AI-powered CRO & UX audit tool that automatically scans your pages, identifies UX issues, and gives you actionable optimization suggestions to increase conversions. Try it for free, no card, no commitment.

    Free CRO Audit
    Share this article
    LinkedIn X

    About the author

    Founder of EyeCaptain. Writes about conversion rate optimization, UX analysis and the neuromarketing behind pages that actually sell.

    More articles by Dimitris Andreadakis