WCAG 2.2 Target Size and Focus Visibility: What Changed for Web Design

Most accessibility conversations still default to color contrast, because it's the easiest thing to point a scanner at. But since the European Accessibility Act's enforcement window opened across all 27 EU member states on June 28, 2025, and WCAG 2.2 became the reference version auditors actually check against, two quieter criteria have been catching far more real interfaces off guard: target size and focus visibility. Neither is exotic. Both are things a design system either handles by default or silently gets wrong on every screen it ships.

What WCAG 2.2 actually added

WCAG 2.2 became a W3C Recommendation in October 2023, and it layered new success criteria on top of 2.1 rather than replacing it. Two of them matter most for day-to-day interface work. Success Criterion 2.5.8, Target Size (Minimum), is a Level AA requirement: interactive targets need at least 24 by 24 CSS pixels, or enough spacing around a smaller target that its effective hit area reaches that size — unless the target is inline in a sentence, its size is set by the user agent and not the author, it's covered by an existing legal exception, or an equivalent, adequately sized control for the same action exists elsewhere on the page.

Success Criterion 2.4.11, Focus Not Obscured (Minimum), is also Level AA: when a component receives keyboard focus, at least part of it has to stay visible, not fully hidden behind a sticky header, a cookie banner, or a chat widget. A related criterion, 2.4.13 Focus Appearance, sets minimum size and contrast for the focus indicator itself — but that one landed at Level AAA, so it's not required for standard AA conformance. It's still worth building to, and we'll get to why.

Why touch targets fail audits even when they 'look fine'

24 by 24 CSS pixels sounds trivial until you actually measure the icon buttons in a typical admin dashboard: a 16px close icon with 4px of padding, a table row's edit and delete glyphs sitting a few pixels apart, a mobile nav's hamburger icon rendered at 20px because it 'reads fine visually.' None of those fail on sight. They fail the moment someone runs a target-size check against the actual clickable bounding box, not the icon's visual size — and that's exactly what an EAA-driven audit now does.

The fix is rarely a redesign. Most of the time it's auditing your design system's icon-button component for its real hit area, not its rendered glyph, and either growing the touch target or adding invisible padding so the interactive region clears 24 by 24 CSS pixels. The spacing exception in 2.5.8 means two 20px targets sitting far enough apart can still pass — so this is a spacing and hit-area problem more often than a visual redesign problem.

The outline: none problem

The most common way teams fail Focus Not Obscured and end up with unusable keyboard navigation isn't a missing focus style — it's outline: none shipped years ago to kill the browser's default focus ring for aesthetic reasons, with no replacement ever added. That single line removes the only visual signal a keyboard or switch-device user gets for where they are on the page, and it's still one of the most common findings in accessibility audits we run today.

The reliable fix is :focus-visible rather than :focus — it lets you style a clear, on-brand focus indicator for keyboard navigation while leaving mouse clicks free of a ring most users don't want to see. We treat WCAG 2.2's AAA-level Focus Appearance criterion as a practical baseline even though it isn't required for AA: a focus indicator with real contrast and a visible perimeter, not a 1px outline that disappears against a similarly colored background, costs almost nothing to design in and prevents an entire category of usability complaints later.

Why this matters more in 2026 than it did a year ago

The European Accessibility Act's enforcement start on June 28, 2025 changed the incentive structure, not just the guidance. It applies to digital products and services sold to consumers anywhere in the EU, regardless of where the company is headquartered, and conforming to EN 301 549 — the EU's technical accessibility standard, which points to WCAG AA — is the most direct path to a presumption of legal conformity. Regulators in France and Germany were already issuing formal notices and investigating complaints against major retailers within months of the deadline, and disability advocacy groups have filed suits independently of any regulator action.

For a client selling into the EU, or a US-based product with any EU user base, WCAG 2.2 AA has moved from 'best practice we should get to eventually' to a real compliance line. Target size and focus visibility are two of the cheapest criteria on that list to fix and two of the most commonly failed, which makes them exactly the kind of finding that damages credibility with a client if a third-party audit catches them first.

How to test target size and focus yourself

You do not need a specialist tool to find most of these problems. A short manual pass on a few key screens will catch the majority.

1. Measure the real hit area. In the browser's developer tools, inspect an icon button and look at the size of the element that receives the click, not the glyph.
2. Check spacing for small targets. If a control is under 24 by 24 pixels, confirm there is enough clear space around it.
3. Tab through the page with the keyboard only. At every step you should see where focus is.
4. Scroll with focus. Tab to a link near a sticky header or banner and confirm it is not covered when it receives focus.
5. Search the code for outline: none, outline: 0 and :focus { outline and check each has a visible replacement.

/* a clear, on-brand focus indicator for keyboard users */
:focus-visible {
  outline: 3px solid #0f6b4c;
  outline-offset: 3px;
  border-radius: 6px;
}

/* make small icon buttons meet the target size */
.icon-button {
  min-width: 44px;
  min-height: 44px;
}

On sticky headers, scroll-margin-top (and scroll-padding-top on the page) keep focused elements from sliding underneath the header when the browser scrolls them into view.

A checklist for your design system

• Icon buttons and form controls have a hit area of at least 24 by 24 CSS pixels, and 44 by 44 on touch-first screens.
• A visible :focus-visible style exists for every interactive component, with enough contrast against its background.
• No component removes the outline without replacing it.
• Sticky headers, cookie banners and chat widgets are tested against keyboard focus.
• Disabled and error states are communicated by more than color.
• These rules are written into the component documentation so new screens inherit them.

What we'd actually recommend

Don't wait for a compliance audit to find this. Run an automated target-size check against your live component library — not your Figma file, the rendered DOM — since padding and margin choices in CSS routinely drift from what a mockup implies. Set a 24 by 24 CSS pixel minimum as a hard rule in the design system's icon-button and control specs, and default to 44 by 44 for anything primarily used on mobile, which clears the WCAG minimum with real margin for thumbs. Audit every outline: none in the codebase and replace it with a deliberate :focus-visible style rather than deleting the rule and hoping the browser default is good enough on your background colors.

If you're building or redesigning for a client with any EU customer base, treat WCAG 2.2 AA as the baseline from day one of the design system rather than a retrofit — it's dramatically cheaper to bake a 24px minimum hit area and a visible focus ring into your component library once than to audit and patch every screen that shipped without them.