Color Contrast and Focus Appearance: The WCAG 2.2 Fixes Behind 83.9% of Failing Sites

Color contrast is not a niche accessibility issue. According to WebAIM's 2026 analysis, it's present on 83.9% of top websites - the single most commonly failed WCAG success criterion by a wide margin. It sits alongside missing alt text, missing form labels, empty links, empty buttons, and missing document language as one of six failure types that together account for 96% of all detected accessibility errors on the web.

WCAG 2.2 added a second, related problem to that list: focus visibility. Success Criterion 2.4.11 (Focus Appearance) and the pattern known as Focus Not Obscured^[2] are now catching interfaces that pass every contrast check but still fail keyboard users the moment they try to navigate.

Both are EN 301 549 obligations under the EAA. EN 301 549 currently maps to WCAG 2.1 AA, but is moving toward WCAG 2.2 as the v4.1.1 revision proceeds toward publication - and contrast and focus visibility are exactly the kind of criteria that get caught in manual audits even when automated scanners give a clean report.

The contrast math, precisely

WCAG defines contrast as a ratio between 1:1 (no contrast) and 21:1 (black on white), calculated from relative luminance. The thresholds that matter in practice:

• 4.5:1 for normal body text (below roughly 18pt regular or 14pt bold)
• 3:1 for large text (18pt+ regular or 14pt+ bold)
• 3:1 for UI components and graphical objects - icons, form field borders, and other non-text elements that convey meaning or state

That last category is the one teams miss most often. Contrast requirements aren't limited to text.

The failure patterns that keep showing up

Light gray text on white. The most common single failure - often a deliberate design choice for a "softer" look that quietly drops below 4.5:1, especially for secondary text, captions, and metadata.

Placeholder text used as a label. Placeholder styling is frequently lighter than body text by default, and once the field is populated, the "label" disappears entirely - a double failure of both contrast and, separately, of having no persistent label at all.

Disabled-looking buttons that are actually interactive. Buttons styled with low-contrast grays to signal "less important" often fall under the 3:1 UI-component threshold, and worse, visually communicate "you can't click this" to sighted users who then avoid a control that actually works.

Brand colors that don't pass. Brand palettes are usually chosen for visual identity, not contrast math. A brand blue or pastel accent used for interactive text or icons on a matching background frequently fails 3:1 or 4.5:1 outright, and "we can't change the brand color" is not a defense a regulator will accept.

Focus Appearance (SC 2.4.11): what actually has to be true

WCAG 2.2's Focus Appearance criterion requires that when an element receives keyboard focus, the indicator must have at least 3:1 contrast against the colors of the adjacent, unfocused element, and it must be sufficiently large - roughly equivalent to a 2px outline around the element's perimeter, or an area of comparable size.

Two extremely common patterns fail this outright:

• outline: none with no replacement. Still one of the most-used lines in production CSS, almost always written to "clean up" a default outline the developer found visually unappealing - without adding any accessible replacement.
• Default browser outlines that don't meet the contrast threshold. Not every default focus ring actually clears 3:1 against every possible adjacent color, particularly on colored buttons or dark-mode interfaces. "The browser draws something" is not the same as "the browser draws something that passes."

A CSS pattern that reliably passes:

:focus-visible {
  outline: 2px solid #1a73e8;
  outline-offset: 2px;
}

Using :focus-visible rather than :focus avoids showing the indicator on mouse clicks while still guaranteeing it on keyboard navigation - but the color and offset still need to be checked against every background the control can appear on, not just tested once against a white page.

Focus Not Obscured: the failure automated tools miss

This is where sticky headers and cookie-consent banners cause damage that has nothing to do with their own accessibility and everything to do with what they cover up. A user tabs through a form; a sticky header or a cookie banner sits fixed at the top or bottom of the viewport; the currently focused field scrolls underneath it and is now invisible - still focused, still receiving keystrokes, but no longer visible to the person using it.

This is one of the most common real-world failures among the new WCAG 2.2 criteria, and it's structurally difficult for automated scanners to catch, because it requires actually tabbing through a live layout and watching what happens to focus relative to fixed-position elements - not just checking each element's contrast or markup in isolation.

How to actually test for these

Automated tools are reliable for flat text-contrast checks but are not reliable for focus-visibility issues, which only appear in the dynamic interaction between keyboard navigation and layout. That means:

1. Run automated contrast scanning across the full design system - text, icons, form borders, disabled/enabled states - not just the homepage.
2. Manually tab through every page template with sticky headers, banners, or modals present, watching whether the focused element stays fully visible at every scroll position.
3. Check focus-indicator contrast against every background the control can realistically appear on - colored buttons, dark mode, hover states - not a single default background.
4. Re-test after any cookie-consent, chat-widget, or third-party banner is added - these are frequently added after the original accessibility audit and never re-tested.

Color contrast has been a known, well-documented requirement for over a decade, and it's still the most common failure on the web. Focus visibility is newer, less tested for, and already showing the same pattern. Both are cheap to fix relative to almost anything else on an accessibility remediation list - and both are exactly the kind of finding that shows up first in a manual EN 301 549 audit.