WCAG 2.2 for Brand Sites: The 2026 Fix List (Focus, Targets, Dragging, Authentication)

What Changed in WCAG 2.2

WCAG 2.2 became a W3C Recommendation in late 2023, and by 2026 it is the standard that accessibility audits reference. For most studios, the existing WCAG 2.1 AA compliance work covered the fundamentals: contrast ratios, keyboard access, alt text, semantic structure.

WCAG 2.2 added nine new success criteria. Most of them refine edge cases or raise the bar on existing requirements. But four of the new criteria cause consistent failures on brand and studio sites because they target interaction patterns that designers rarely think about:

1. Focus Appearance (2.4.11, AA): Focus indicators must meet minimum size and contrast requirements.
2. Target Size (2.5.8, AA): Interactive targets must be at least 24x24 CSS pixels.
3. Dragging Movements (2.5.7, AA): Any function that requires dragging must have a non-dragging alternative.
4. Accessible Authentication (3.3.8, AA): Authentication flows must not require cognitive function tests.

This article covers what each criterion requires and the specific fixes for brand site patterns that commonly fail.

Focus Appearance (2.4.11)

This criterion specifies that keyboard focus indicators must be clearly visible. The minimum requirements:

• The focus indicator must have a contrasting area that is at least as large as a 2px solid outline around the focused element
• The contrast between the focused and unfocused states must be at least 3:1

Brand sites fail this constantly because the first thing most designers do is remove the default browser focus ring. They find it visually jarring and replace it with nothing, or with a subtle color change that does not meet the contrast requirement.

The fixes

Use a visible focus ring. CSS outline with outline-offset is the simplest approach. A 2px solid outline in a color that contrasts with the background meets the criterion.

```

:focus-visible {

outline: 2px solid var(--color-fg);

outline-offset: 3px;

}

```

Using :focus-visible instead of :focus ensures the ring appears only for keyboard navigation, not for mouse clicks. This addresses the designer's concern about visual clutter while maintaining accessibility.

Design the focus indicator as part of the brand. Rather than fighting the focus ring, make it part of the visual language. A focus ring in your brand's accent color, with consistent offset and radius, looks intentional rather than default. Our earlier piece on accessibility for brand sites discussed this approach in detail.

Do not remove outline on custom interactive elements. Custom buttons, cards with click handlers, and interactive components built with divs or spans often lack focus styling entirely. If it is clickable, it needs a focus indicator.

Target Size (2.5.8)

Interactive targets must be at least 24x24 CSS pixels. This applies to links, buttons, form inputs, and any other element that responds to pointer input. The criterion has an exception for inline links within text, but standalone interactive elements must meet the minimum.

Brand sites fail this in predictable places:

Small navigation links. A header nav with text links set in 12px monospace type. The text itself might be 12px tall and 60px wide. The clickable area needs to be at least 24px tall. Add padding.

Icon buttons without sufficient padding. A close button for a modal that is a 16px SVG with no padding. The tap target is 16x16, which fails. Add padding or use min-height and min-width on the button element.

Footer links stacked tightly. A list of footer links with 8px vertical spacing between them. Each link's target overlaps with adjacent links, and individual targets may be shorter than 24px. Increase spacing or padding.

Form elements. Checkboxes and radio buttons at their default browser size are often smaller than 24px. Custom-styled form elements should ensure the interactive area meets the minimum.

The fix pattern

For any interactive element that might be too small:

```

.interactive-element {

min-height: 24px;

min-width: 24px;

padding: 4px 8px;

display: inline-flex;

align-items: center;

}

```

This ensures the element meets the minimum target size regardless of its text content. For icon-only buttons, increase the minimum to 44x44px for comfortable touch targets (WCAG recommends 44px as the enhanced criterion at AAA).

Dragging Movements (2.5.7)

Any functionality that uses a dragging movement must have a non-dragging alternative. This means:

• Drag-to-reorder lists must also support button-based reordering
• Slider inputs must also accept direct value entry
• Drag-to-sort columns must also support sort buttons
• Map panning must also support directional buttons or scrolling

Brand sites hit this less often than web apps, but there are common patterns:

Image carousels with swipe navigation. If the carousel only responds to swipe gestures, it fails. Add previous/next buttons as an alternative.

Testimonial sliders. Same issue. Swipe-only navigation needs button alternatives.

Before/after image comparison sliders. The draggable handle that reveals one image over another needs a button-based alternative or direct percentage input.

The fix is usually straightforward: add visible navigation buttons alongside the swipe gesture. This also improves the experience for mouse users who find drag interactions cumbersome.

Accessible Authentication (3.3.8)

Authentication flows must not rely on cognitive function tests. This means:

• No CAPTCHAs that require solving puzzles, identifying objects, or reading distorted text
• No pattern-based authentication (draw a shape)
• No memory-based tests (remember and re-enter a sequence)

Exceptions exist for standard password fields (typing a memorized password is allowed) and copy-paste authentication (entering a code from an email or authenticator app).

For brand sites, the most common failure is contact forms protected by image-based CAPTCHAs. The fix is to use an invisible CAPTCHA service (like Cloudflare Turnstile or hCaptcha in managed mode) that validates users without visible puzzles.

If the site uses a password-protected staging area or client review zone, ensure the authentication method is standard username/password or token-based, not a cognitive puzzle.

The Audit Workflow

For existing brand sites, audit for WCAG 2.2 compliance in this order:

1. Focus indicators first. Tab through every page and check that every interactive element has a visible focus indicator. This is the fastest audit and catches the most common failures.

1. Target sizes second. Use the DevTools element inspector to check the computed size of interactive elements. Pay attention to navigation links, small buttons, and footer links.

1. Dragging movements third. Identify every drag interaction on the site and verify that a non-dragging alternative exists.

1. Authentication fourth. Review contact forms and any gated content for cognitive function tests.

Use automated tools (axe, Lighthouse accessibility audit) as a starting point, but do not rely on them exclusively. Automated tools catch about 30 to 40% of accessibility issues. The rest require manual testing with a keyboard, screen reader, and visual inspection.

FAQ

Does WCAG 2.2 replace 2.1?

WCAG 2.2 supersedes 2.1. All 2.1 success criteria remain, and 2.2 adds new ones. If you meet WCAG 2.2 AA, you also meet 2.1 AA. One criterion from 2.1 (4.1.1 Parsing) was removed in 2.2 because modern HTML parsers have made it obsolete.

Is WCAG 2.2 legally required?

This depends on jurisdiction. In many countries, accessibility laws reference WCAG AA as the technical standard. As legal frameworks update, they are adopting 2.2 as the reference version. Regardless of legal requirements, meeting 2.2 AA is the responsible baseline for professional websites.

Can I fix these issues retroactively?

Yes. All four criteria described above can be addressed with CSS and HTML changes. Focus indicators are CSS. Target sizes are CSS padding. Dragging alternatives are additional HTML elements. Authentication changes may require backend adjustments if using a CAPTCHA service.

The Takeaway

WCAG 2.2 does not fundamentally change how accessible websites are built. It raises the bar on four specific interaction patterns that brand sites commonly get wrong. The fixes are CSS padding, focus outlines, navigation buttons, and removing puzzle CAPTCHAs. None of these compromises the visual design. All of them make the site usable by more people.