Why does WCAG 2.2 matter right now, in 2025?

Accessibility compliance is no longer a nice-to-have. The Web Content Accessibility Guidelines 2.2 became a W3C Recommendation in October 2023, introducing nine new success criteria on top of the existing 2.1 baseline. Level AA is the legally relevant threshold in most jurisdictions. In the UK, the Equality Act 2010 requires service providers to make reasonable adjustments so that disabled people can access services -- and courts have consistently interpreted websites as covered services.

Across the EU, the European Accessibility Act (Directive 2019/882) requires that most private-sector digital products and services meet EN 301 549, which references WCAG 2.1 AA as its technical standard. The deadline for compliance is 28 June 2025. Member states are implementing their own enforcement regimes with penalties that vary by country, but fines and injunctions are real possibilities. The US remains governed by Section 508 for federal agencies and by ADA Title III as interpreted through case law -- over 4,000 federal accessibility lawsuits were filed in 2023 alone.

The point is simple: if you are building in Next.js or Astro today, baking in WCAG 2.2 AA from the start is cheaper than retrofitting later, and it is legally necessary for many clients.

What did WCAG 2.2 actually change, and which new criteria hit component builders hardest?

The nine new success criteria in 2.2 are not evenly distributed in effort. Four of them have direct implications for how you write React components or Astro islands.

2.4.11 Focus Not Obscured (Minimum) requires that a focused component is not entirely hidden by sticky headers, cookie banners, or chat widgets. This is a genuine problem on sites with fixed navigation bars. You need to account for scroll-margin-top in CSS and ensure that sticky elements do not consume too much vertical space.

2.4.12 Focus Not Obscured (Enhanced) is the AAA version -- no part of the focus indicator may be hidden -- but knowing it exists shapes good defaults.

2.5.3 Target Size (Minimum) at AA requires interactive targets to be at least 24x24 CSS pixels, or for the target to have sufficient spacing so that a 24px circle centred on it does not intersect another target or its spacing. This catches small icon buttons, close-drawer icons, and inline text links packed tightly together.

3.2.6 Consistent Help means that if a help mechanism -- a chat link, a phone number, a contact form -- appears across multiple pages, it must appear in the same relative order in the DOM each time. This is trivially solved by a shared layout component, but it is easy to break on sites where marketing teams inject widgets inconsistently.

3.3.7 Redundant Entry states that users should not have to re-enter information already provided in the same session. Multi-step checkout flows and application forms are the main targets here.

How do you structure accessible components in Next.js?

Next.js is a React framework, so the fundamentals are React fundamentals -- but Next.js adds some specific considerations around routing and server components.

Start with the document outline. Every page rendered by Next.js should have exactly one h1, and heading levels should not skip. The App Router in Next.js 13+ makes it easy to co-locate layout files, so a shared RootLayout that renders a skip-navigation link as its very first child is the right architectural move. A skip link styled with sr-only until focused -- using Tailwind's built-in utility or a hand-rolled CSS equivalent -- lets keyboard users bypass repeated navigation. This addresses WCAG 2.4.1 Bypass Blocks.

Focus management after client-side navigation is the area where Next.js most commonly fails out of the box. When a user clicks a link and the router renders a new page without a full browser reload, screen readers do not automatically announce the new page title. The Next.js documentation acknowledges this and notes that the App Router focuses the page body by default, but this is not enough for all screen reader and browser combinations. The safest pattern is to place a visually hidden h1 with tabIndex={-1} and call .focus() on it inside a useEffect that fires on route change, or to use a package like @radix-ui/react-focus-scope to manage focus deliberately.

For interactive components -- modals, dropdowns, accordions, tab panels -- my team at Social Animal treats the ARIA Authoring Practices Guide (APG) as a specification document, not a suggestion. The APG provides keyboard interaction patterns and required ARIA attributes for dozens of widget types. A modal dialog, for example, must trap focus within itself while open, return focus to the triggering element when closed, and carry role="dialog", aria-modal="true", and an accessible name via aria-labelledby.

Colour contrast is enforced at the design token level. WCAG 1.4.3 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt or 14pt bold). Programmatic checking during development using axe-core -- wired into Jest, Playwright, or Storybook -- catches the obvious failures before they reach production.

How does Astro's architecture change your accessibility approach?

Astro is fundamentally different from Next.js because it ships zero JavaScript by default and uses an islands architecture. This has accessibility implications that are both positive and negative.

The positive: most content in an Astro site is static HTML. Static HTML, rendered correctly, is inherently more accessible than a JavaScript-heavy SPA. There is no hydration mismatch to worry about, no flash of unstyled content, and no client-side routing unless you deliberately opt in with @astrojs/prefetch or the View Transitions API.

The complication: Astro's View Transitions API, available from Astro 3.0 onwards, introduces client-side navigation, which recreates the focus management problem described above. The Astro team added an astro:page-load lifecycle event precisely to let developers restore focus after a transition. You should listen to this event and move focus to the main content landmark or a focused heading, identical to the Next.js pattern.

For interactive islands -- a React or Preact component hydrated with client:load or client:idle -- all the same ARIA rules apply. The difference is that you must be deliberate about which components justify the JavaScript payload. A disclosure widget that can be built with the native HTML details/summary elements, for instance, needs no JavaScript and is accessible by default. Reach for framework components only when native HTML cannot express the interaction pattern.

Form validation in Astro's server-first model works well with WCAG 3.3.1 (Error Identification) and 3.3.3 (Error Suggestion). Returning validation errors server-side, rendered into the page with aria-describedby pointing error messages at their corresponding inputs, is cleaner and more accessible than client-side validation-only patterns where errors appear after JavaScript executes.

What does a practical testing workflow look like for WCAG 2.2 AA?

Automated tools catch roughly 30-40% of accessibility issues, according to research by Deque. The rest require manual testing and screen reader verification. This does not mean automation is useless -- it means you need both.

Here is the stack I use on every Next.js and Astro project.

Integrate axe-core into your component tests via jest-axe. Write a test for every new component that runs axe(container) and asserts no violations. This catches missing labels, invalid ARIA, and contrast failures at the unit level.

Add Playwright tests with @axe-core/playwright for page-level checks. Run these against a local server as part of your CI pipeline. This catches issues that only appear in the context of a full page -- obscured focus, missing skip links, inconsistent help landmarks.

Use the WAVE browser extension and browser-native accessibility trees (the Accessibility tab in Chrome DevTools and Firefox's Accessibility panel) for spot-checking during development.

Test with real screen readers. NVDA with Firefox on Windows is a reliable free combination. VoiceOver on macOS and iOS covers a significant portion of actual users. Screen reader behaviour is not fully predictable from ARIA alone -- you will find surprises.

Manual keyboard-only testing on every interactive component is non-negotiable. Tab, Shift-Tab, Enter, Space, Escape, and arrow keys must all behave as the APG specifies for the widget type in question.

When does a rebuild from WordPress or Wix make accessibility easier rather than harder?

Legacy CMS platforms are not inherently inaccessible, but in practice, most WordPress and Wix sites carry significant accessibility debt. Page builders like Elementor and Divi generate deeply nested, semantically incorrect HTML. Third-party plugins add their own widgets without conforming to any consistent ARIA pattern. The result is often a site where fixing one component breaks another because global CSS overrides have unpredictable scope.

I have been through this with clients. A rebuild in Next.js or Astro gives you a clean semantic foundation. You control every component, every heading order, every ARIA attribute. You can establish design tokens for colour contrast from day one. That is categorically easier than auditing a WordPress theme and negotiating with a page builder over generated markup.

That said, a rebuild is a significant investment. For clients facing the June 2025 European Accessibility Act deadline who have complex, content-heavy WordPress sites, a phased approach -- fix the critical path (home, product, checkout, contact) on the existing platform while planning a full rebuild -- is often the pragmatic choice. The critical legal risk is in the user journey, not on every internal page.

FAQ

What is the difference between WCAG 2.1 AA and WCAG 2.2 AA?

WCAG 2.2, published in October 2023, adds nine new success criteria to the existing 2.1 set. The most practically significant at AA level are Focus Not Obscured (2.4.11), Target Size Minimum (2.5.3), Consistent Help (3.2.6), and Redundant Entry (3.3.7). Criterion 4.1.1 (Parsing) was removed in 2.2. The W3C's comparison page details every change.

Does the European Accessibility Act apply to UK businesses?

Not directly, since the UK left the EU. However, UK businesses selling services into EU markets need to comply with national implementations of the EAA by 28 June 2025. UK-only businesses remain subject to the Equality Act 2010 and the Public Sector Bodies Accessibility Regulations 2018, the latter applying to public sector organisations.

Can Astro's static output ever fail WCAG checks?

Yes. Static HTML can have missing alt text, poor heading structure, insufficient colour contrast, and missing form labels. Framework choice does not guarantee accessibility -- the quality of the markup does. Astro makes it easier to write clean semantic HTML, but it does not enforce it.

How should I handle third-party embeds like YouTube videos or social feeds?

Third-party iframes must have a descriptive title attribute. For video content, captions are required under WCAG 1.2.2. You cannot control the accessibility of the content inside a third-party iframe, but you can control its title, its surrounding context, and whether you choose to embed it at all. Where a vendor's embed is inaccessible, providing an alternative -- a transcript, a direct link -- is the pragmatic fallback.

What is the minimum target size in WCAG 2.2 and how do I check it?

The AA requirement is 24x24 CSS pixels for the target itself, with the caveat about spacing described in success criterion 2.5.8. Browser DevTools can measure element dimensions. For icon-only buttons, the practical fix is to add padding so the clickable area reaches 24px even if the icon glyph is smaller -- a pattern that also improves usability on touch devices significantly.