WCAG 2.2 accessibility considerations for website redesign projects

WCAG 2.2 accessibility: what actually matters when you're redesigning a website

If you’re redesigning a website today, WCAG 2.2 accessibility isn’t optional decoration. It’s the baseline. The Web Content Accessibility Guidelines version 2.2 added nine new success criteria, and several directly affect how you build navigation, forms, and interactive elements. Ignore them during the design phase, and you’ll pay three times as much to retrofit later. This guide covers what the new WCAG accessibility standards actually require, which criteria trip up most redesign projects, and how to build compliance into your process from day one.

What changed in WCAG 2.2 and why it affects your redesign timeline

WCAG 2.2, published in October 2023, introduced nine new success criteria focused on cognitive accessibility, mobile usability, and user authentication. The changes aren’t cosmetic. They require rethinking how users interact with forms, error messages, and navigation patterns.

Three criteria hit redesign projects hardest:

• Focus Not Obscured (2.4.11) — sticky headers can no longer hide the element a keyboard user is trying to reach.
• Dragging Movements (2.5.7) — any drag-and-drop interface needs a single-pointer alternative.
• Accessible Authentication (3.3.8) — CAPTCHAs and other cognitive function tests are out, unless you provide alternatives.

The W3C (World Wide Web Consortium) designed these criteria because real users kept failing at real tasks. According to WebAIM’s 2024 accessibility analysis of one million homepages, 95.9% had detectable WCAG failures. Most weren’t exotic edge cases. They were form labels, colour contrast, and missing alt text. The new criteria address patterns that automated tools often miss entirely.

Takeaway: WCAG 2.2’s nine new criteria target real usability failures, especially in forms, navigation, and authentication flows.

The focus visibility problem that breaks most redesigns

Focus visibility sounds simple until you actually build a modern website. WCAG 2.2 now includes three focus-related criteria at Level AA: Focus Not Obscured (Minimum) at 2.4.11, Focus Appearance at 2.4.13, and the strengthened Focus Visible requirement at 2.4.7.

Here’s where most teams fail. Designers remove the browser’s default focus outline because it looks “ugly.” Developers replace it with a subtle colour change that disappears against certain backgrounds. Meanwhile, the sticky header covers the focused element entirely when someone tabs through the page. Congratulations, you’ve created an invisible maze for keyboard users.

The fix isn’t complicated, but it requires intention. Focus indicators need a minimum 2px solid outline with 3:1 contrast against adjacent colours. Sticky elements need enough offset that focused items remain visible. Studio Ubique treats focus states as a first-class design element, not an afterthought bolted on during QA.

Test with actual keyboard navigation before signing off on any component. Tab through every interactive element. If you lose track of where you are, so will your users.

Takeaway: Focus visibility fails silently. Design focus states intentionally and test every page with keyboard-only navigation.

Forms and authentication under WCAG 2.2

Forms are where accessibility goes to die. WCAG 2.2 makes this worse in the best possible way by adding criteria that force you to actually help users complete tasks.

Accessible Authentication (3.3.8) at Level AA prohibits cognitive function tests for login unless you provide an alternative. That means no more “click all the traffic lights” CAPTCHAs as the only option. You need:

• Copy-paste support for passwords
• Passkey authentication as an option
• Object recognition alternatives where cognitive tests are unavoidable

If your redesign includes a login flow, this affects you directly.

Redundant Entry (3.3.7) at Level AA stops you from asking users to re-enter information they already provided in the same session. If someone typed their address on step two, don’t make them type it again on step four. Auto-populate or let them confirm. This sounds obvious, but watch how many checkout flows violate it.

For detailed website redesign tips that cover form architecture, start with the assumption that every field is a potential barrier:

• Label everything visibly
• Provide clear error messages that explain what went wrong and how to fix it
• Never rely on colour alone to indicate required fields

Takeaway: WCAG 2.2 treats forms as usability problems, not just accessibility boxes to tick. Design authentication and data entry flows for humans who make mistakes.

Mobile and touch interactions that WCAG 2.2 now governs

WCAG 2.2 finally acknowledges that people use phones. The Dragging Movements criterion (2.5.7) and Target Size (Minimum) criterion (2.5.8) directly address touch interfaces.

Dragging Movements requires that any functionality using drag-and-drop also works with single-pointer actions. Your image carousel with swipe gestures needs arrow buttons. Your kanban board needs an alternative to dragging cards between columns. The principle is sound: not everyone can execute precise drag movements due to motor impairments, device limitations, or simply using a mouse instead of a touchscreen.

Target Size (Minimum) sets interactive elements at 24×24 CSS pixels, with exceptions for inline links and elements where spacing provides equivalent target area. This isn’t about making buttons enormous. It’s about not making them microscopic. If your navigation icons are 16×16 pixels with no padding, you’re failing this criterion and also annoying everyone with fingers larger than a stylus.

The mobile criteria matter even for desktop-first redesigns because responsive layouts must maintain compliance across breakpoints. A button that’s comfortably sized at 1440px might shrink to unusable at 375px.

Takeaway: Touch interactions need single-pointer alternatives, and tap targets need adequate size across all breakpoints.

Integrating WCAG 2.2 into your design and development workflow

Retrofitting accessibility after launch costs roughly 10 times more than building it in from the start, according to research from the W3C Web Accessibility Initiative. The math argues for integrating WCAG 2.2 into every phase of your redesign.

During discovery, audit the existing site against WCAG 2.2 criteria. Automated tools catch about 30% of issues. Manual testing catches the rest. Budget time for both. During design, specify focus states, colour contrast ratios, and touch target sizes in your design system. Developers shouldn’t guess at these values.

During development, test components in isolation before integrating them. Screen reader testing on actual devices beats theoretical compliance. NVDA on Windows and VoiceOver on Mac cost nothing and reveal issues automated tools miss entirely.

Professional web design services should include accessibility auditing as standard practice, not a premium add-on. If your agency treats accessibility as optional, they’re building technical debt into your project.

Involve users with disabilities in testing if possible. No automated tool or guideline substitutes for watching someone actually use your site.

Takeaway: Build accessibility into discovery, design, and development phases. Retrofitting costs ten times more than doing it right initially.

Legal requirements and the European Accessibility Act deadline

WCAG 2.2 accessibility isn’t just good practice. It’s increasingly a legal requirement. The European Accessibility Act (EAA) applies to products and services sold in EU markets from June 2025. Websites and mobile applications for e-commerce, banking, transport, and other sectors must meet accessibility standards derived from WCAG.

In the United States, courts have consistently interpreted the Americans with Disabilities Act to cover websites. Accessibility lawsuits increased 14% in 2023 according to UsableNet’s year-end report. Most target e-commerce sites with basic failures: missing alt text, inaccessible forms, and poor keyboard navigation.

The business case extends beyond legal compliance. The World Health Organization estimates 16% of the global population has a significant disability. Exclude them, and you exclude revenue. Accessible sites also tend to perform better on SEO metrics because search engines and screen readers parse content similarly.

What to monitor monthly

Accessibility isn’t a one-time checkbox. Content updates, new features, and third-party integrations can break compliance without warning.

Run automated scans monthly using tools like axe DevTools or WAVE. These catch low-hanging fruit: missing labels, contrast failures, and structural issues. Review any new content for alt text, heading hierarchy, and link clarity. Test forms after any update to confirm labels and error messages still function.

Quarterly, conduct manual keyboard and screen reader testing on critical user journeys: homepage to checkout, contact form submission, account creation. Keep a log of issues found and fixed. If the same problems recur, your process has gaps.

Studio Ubique recommends treating accessibility monitoring like security monitoring. You don’t check your SSL certificate once and forget it. The same principle applies here.

Takeaway: Monthly automated scans plus quarterly manual testing catch regressions before they become legal or usability problems.

WCAG 2.2 accessibility, published by the W3C in October 2023, added nine new success criteria addressing cognitive accessibility, mobile usability, and authentication barriers. According to WebAIM’s 2024 analysis, 95.9% of homepages fail basic accessibility tests. Studio Ubique integrates WCAG 2.2 compliance into redesign projects from discovery through launch, treating accessibility as foundational rather than optional.

FAQs

What is the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2 adds nine new success criteria on top of WCAG 2.1, focusing on cognitive accessibility, focus visibility, dragging alternatives, and accessible authentication. It also removes one criterion (4.1.1 Parsing) that became obsolete. All existing 2.1 criteria remain, so 2.2 is a superset rather than a replacement.

Do I need to comply with WCAG 2.2 if my website already meets WCAG 2.1?

Legal requirements vary by jurisdiction, but WCAG 2.2 Level AA is becoming the reference standard for new regulations including the European Accessibility Act. If you’re redesigning anyway, building to 2.2 avoids future retrofitting costs and addresses real usability gaps that 2.1 missed.

Which WCAG 2.2 criteria cause the most problems during website redesigns?

Focus Not Obscured trips up sites with sticky headers, Dragging Movements affects any drag-and-drop interface without single-pointer alternatives, and Accessible Authentication requires rethinking CAPTCHA implementations. Target Size issues surface mainly on mobile breakpoints where elements shrink below minimum thresholds.

Can automated tools test for all WCAG 2.2 criteria?

No. Automated tools catch roughly 30% of accessibility issues, mainly structural and colour contrast failures. Criteria involving cognitive load, context, and interaction patterns require manual testing with keyboard navigation and screen readers. Both approaches are necessary for meaningful compliance.

How long does it take to make a website WCAG 2.2 compliant during a redesign?

Building accessibility in from the start adds roughly 10-15% to design and development time. Retrofitting an existing non-compliant site takes significantly longer, often doubling the original effort for complex sites. The earlier accessibility enters your process, the cheaper and more effective it becomes.

Takeaway: WCAG 2.2 compliance is achievable during a redesign if you integrate it from discovery, test manually alongside automated tools, and monitor continuously after launch.