WCAG 2.2 accessibility considerations for website redesign projects

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

A redesign is the cheapest moment you will ever get to deal with accessibility, and the most expensive moment to ignore it. WCAG 2.2 is the baseline now, not a layer of polish you add at the end. Version 2.2 of the Web Content Accessibility Guidelines added nine new success criteria, and several of them change how you build navigation, forms, and interactive elements. Skip them during design and you pay to retrofit them later, at a worse rate. This is what the new criteria actually require, where redesign projects tend to trip, and how to build compliance in from the first week.

What WCAG 2.2 added

WCAG 2.2 was published in October 2023. Its nine new success criteria focus on cognitive accessibility, mobile usability, and authentication, and they change how users get through forms, error messages, and navigation in ways you cannot paper over.

Three of them hit redesign projects hardest. Focus Not Obscured (2.4.11) means a sticky header can no longer cover the element a keyboard user is tabbing to. Dragging Movements (2.5.7) means any drag-and-drop interface needs a single-pointer alternative. Accessible Authentication (3.3.8) means cognitive function tests like “click all the traffic lights” can no longer be the only way through a login.

The W3C wrote these criteria because real users kept failing real tasks. WebAIM’s annual analysis of a million home pages consistently finds detectable WCAG failures on around 96 percent of them. Most are not exotic edge cases. They are missing form labels, poor colour contrast, and absent alt text, the same handful of failures year after year, and the new criteria target patterns that automated tools tend to miss.

Focus visibility, the failure nobody sees

Focus visibility sounds trivial until you build a modern site. WCAG 2.2 adds focus-related criteria at Level AA, Focus Not Obscured (2.4.11) and Focus Appearance (2.4.13), on top of the existing Focus Visible requirement (2.4.7).

Here is where teams fail. A designer removes the browser’s default focus outline because it looks ugly. A developer replaces it with a faint colour shift that vanishes against half the backgrounds on the site. Meanwhile the sticky header covers the focused element completely when someone tabs down the page. The result is an invisible maze, and only keyboard users ever walk into it.

The fix is simple enough, it just has to be deliberate. A focus indicator needs a clearly visible outline, roughly two pixels, with at least 3:1 contrast against what sits next to it. Sticky elements need enough offset that a focused item stays in view. Studio Ubique treats focus states as a real part of UX and UI design, with a place in the design system, not something bolted on during QA. Test it the only way that works: tab through every interactive element with the keyboard. If you lose track of where you are, so will the people who navigate that way every day.

Forms and authentication under WCAG 2.2

Forms are where accessibility goes to die, and WCAG 2.2 makes that harder to ignore, in the best possible way.

Accessible Authentication (3.3.8) rules out cognitive function tests as the only route through a login. A “select every motorbike” CAPTCHA cannot stand alone. You give people a real way through: password fields that allow copy and paste, passkey support, and an object-recognition alternative where a cognitive test is genuinely unavoidable. If the redesign touches a login flow at all, this one is yours to solve.

Redundant Entry (3.3.7) stops you asking for information the user already gave you in the same session. If they typed an address at step two, do not ask again at step four, auto-fill it or let them confirm it. It sounds obvious until you watch how many checkout flows break the rule.

The rest of form accessibility is unglamorous and well known. Label every field visibly. Write error messages that say what went wrong and how to fix it. Never let colour alone carry meaning, a required field marked only in red is invisible to a good share of your visitors.

Touch interactions WCAG 2.2 now governs

WCAG 2.2 finally acknowledges that people use phones. Dragging Movements (2.5.7) requires that anything you can do by dragging also works with a single pointer. An image carousel with swipe gestures needs arrow buttons. A kanban board needs a way to move a card without dragging it. Not everyone can perform a precise drag, whether because of a motor impairment, a device limitation, or simply a mouse instead of a touchscreen.

Target Size (2.5.8) sets interactive elements at a minimum of 24 by 24 CSS pixels, with sensible exceptions for inline links and elements that have enough spacing around them. Sixteen-pixel navigation icons with no padding fail this criterion and quietly annoy anyone whose fingers are larger than a stylus. It matters even for desktop-first redesigns, because a button that is comfortable at 1440 pixels can shrink to unusable at 375.

Build it into the workflow

Accessibility is far cheaper to build in than to retrofit. W3C’s own business-case guidance puts it plainly: costs are lower when you make a new site accessible than when you fix an existing one. The argument for handling it in every phase of a redesign is mostly an argument about money.

During discovery, audit the current site against WCAG 2.2. During design, write focus states, contrast ratios, and target sizes into the design system, so developers are not guessing at values. During development, test components in isolation before they are wired together. Automated tools are useful and catch maybe a third of issues, the structural and contrast failures. The rest needs manual testing, keyboard navigation, and a screen reader on a real device. NVDA on Windows and VoiceOver on Mac cost nothing and surface problems no scanner will. If you can, watch someone who actually relies on assistive technology use the site, because no guideline substitutes for that.

Accessibility auditing belongs in ordinary web design work as standard practice, not as a premium line item. An agency that treats it as optional is quietly building technical debt into your project. And the work does not end at launch, a content update, a new feature, or a third-party embed can break compliance without anyone noticing, so re-test after changes the same way you would re-check a security setting.

The legal clock

WCAG 2.2 accessibility is good practice, and it is also, increasingly, the law. The European Accessibility Act has been in force since June 2025, and it requires websites and apps in e-commerce, banking, transport, and several other sectors to meet accessibility standards built on WCAG. In the United States, courts have largely read the Americans with Disabilities Act as covering websites, and accessibility lawsuits keep arriving, mostly aimed at e-commerce sites with basic failures, missing alt text, inaccessible forms, weak keyboard support.

The business case runs past the legal one. The World Health Organization estimates that 1.3 billion people, about 16 percent of the world, live with a significant disability. Build a site they cannot use and you have excluded that share of your market on purpose. Accessible sites also tend to do better in search, because a search engine reads a page in much the same structured way a screen reader does.

Where Studio Ubique fits

A redesign done well builds WCAG 2.2 in from discovery through launch, treating accessibility as part of the foundation rather than a compliance scramble before go-live. That is the cheaper path, the lower-risk path, and the one that produces a site more people can actually use. If a redesign is on your roadmap, that is the moment to get it right.

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 to WCAG 2.1, covering cognitive accessibility, focus visibility, dragging alternatives, and accessible authentication. It also retires one criterion, 4.1.1 Parsing, which had become obsolete. Every other 2.1 criterion still applies, so 2.2 is a superset, not a replacement.

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

Legal requirements vary by country, but WCAG 2.2 Level AA is becoming the reference point for newer regulation, including the European Accessibility Act. If you are redesigning anyway, building to 2.2 avoids a future retrofit and closes real usability gaps that 2.1 left open.

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.