Checking Contrast for Button and UI Component States

Checking Button and UI Component Contrast (Hover, Disabled States)

A button's fill color and label text usually get a careful contrast check before launch, but the border around an outline button, or the ring around a focus state, quietly gets skipped far more often. WCAG covers that gap under success criterion 1.4.11, the non-text contrast rule, which requires visible interface boundaries and states to reach 3:1 against their surrounding color,¹ a separate and lower bar than the 4.5:1 body text needs. Testing a button's border, disabled state, and hover treatment here, one pair at a time, catches the interface elements a text-focused contrast review tends to walk right past.

The UI component row most contrast checks skip entirely

Most contrast audits focus on text, since that's where the highest-profile failures live, but WCAG's 1.4.11 criterion covers a different category: the visual boundaries and states of interface components like button outlines, input borders, and focus rings. A design review that checks every heading and paragraph but never opens this tool on a border color has only covered half of what WCAG actually requires.

Why default design-system grays often fail this specific threshold

A design system's default muted border color, chosen to look subtle and unobtrusive against a white background, is frequently the exact color that fails 1.4.11's 3:1 requirement.² A slate gray border like #94a3b8 on white, for instance, reads as a soft, tasteful boundary to the eye while sitting well under the ratio the guideline actually requires, precisely because subtlety and sufficient contrast pull in opposite directions. Design teams rarely set out to fail this rule; they simply prioritize a quiet visual tone over a specific ratio number nobody checked.

The UI row in the preview panel above checks exactly this scenario. Unlike the text rows, it shows only a single AA badge, since WCAG defines no enhanced AAA tier for non-text contrast, meaning there's no stricter target to aim for beyond the one 3:1 bar every visible boundary needs to clear. Once that single badge turns green, the boundary color is done, with nothing further to chase toward a higher tier.

Hover and focus states need their own separate check

A button's default border is only the first check, not the last one. Hover, focus, and active states frequently swap in a different color entirely, and each of those states needs its own pass against 1.4.11 rather than inheriting a pass from the resting state. A design system that only checks the resting border and assumes every interactive variant inherits the same result is checking the easiest state and skipping the rest.

A focus ring in particular carries real accessibility weight, since keyboard users rely on it to track where they are on the page,³ which makes a low-contrast focus indicator a functional barrier, not just a cosmetic shortcoming. Someone tabbing through a long form with a faint focus ring can lose their place entirely, in a way a mouse user navigating the same page would never notice.

Disabled states and where WCAG intentionally looks away

Disabled controls occupy a genuine exception in WCAG's guidance: a button or input that is fully disabled, inert, and cannot be interacted with is not required to meet 1.4.11's contrast threshold at all,¹ since a control a user cannot act on carries less risk from being visually faint. That exception is narrow and specific, not a blanket excuse to leave every muted gray in a design system unchecked.

The exception ends the moment a control becomes interactive again

That exception evaporates the instant the same element becomes interactive, whether that's a form field unlocking after a previous step or a submit button re-enabling once required fields are filled.⁴ Multi-step forms and wizard-style flows are the most common place this transition gets missed, since the disabled-state color was approved once and never revisited for the enabled version.

A gray so faint it's barely visible is a defensible choice while a button stays genuinely disabled, but the same color needs a real contrast check the moment it can be clicked, since at that point it's a functional control again, not a placeholder.⁵ Type that exact gray into the fields above the moment a control regains interactivity, rather than assuming the disabled-state shade was ever meant to double as the active one.

When to use this

Use this guide when auditing a button, input, or focus ring for WCAG success criterion 1.4.11, whenever you want to check a specific border or state color that a text-only contrast review would otherwise miss.

Examples

Foreground #94a3b8, background #ffffff

The UI component row fails 3:1 here, even though the border reads as a tasteful, subtle line to the eye, which is exactly the kind of near-miss a visual review alone tends to approve.

Foreground #64748b, background #ffffff

Darkening the border by roughly one design-token step is often enough to clear 3:1 without the boundary reading as heavy or out of place.