European Accessibility Act
EAA compliance for Next.js: WCAG 2.1 AA checklist & fixes
Next.js gives you all the primitives you need for accessible apps — but accessibility is a code discipline, not a framework setting. The most common Next.js-specific issues are focus loss on client-side route changes, dynamic imports stripping landmarks, and React Server Components that render heading hierarchies inconsistently across nested layouts. The dominant React meta-framework for production sites; chosen by Stripe, Notion, TikTok, OpenAI.
- Category
- Web framework
- Standard
- WCAG 2.1 Level AA via EN 301 549
- Deadline
- 28 June 2025 (EU consumer services)
- Risk for B2C
- High — public-facing, consumer-billed
What the EAA actually requires from a Next.js site
Next.js hands developers every primitive needed for an accessible app, so under the EAA the obligation is a code-discipline requirement rather than a configuration toggle. The framework-specific failures that EN 301 549 forces you to address are focus loss on client-side route changes via next/link, landmarks disappearing when components load through next/dynamic with ssr:false, and heading hierarchies rendering inconsistently across nested Server Component layouts. Because Next.js server-renders real HTML, an auditor evaluates the rendered output, so the requirement is that the SSR payload and post-hydration state both stay AA.
Next.js is the framework of choice for well-funded product companies and larger consumer platforms, so an in-scope Next.js app is often a high-traffic B2C service where a market-surveillance authority's percentage-of-turnover penalty (up to 4% in France) is a genuine threat rather than a theoretical one. These teams also frequently serve US users, layering ADA litigation risk on top of the EAA exposure. The flip side is that these organisations usually have the engineering maturity to fix issues quickly once they are surfaced, so the risk is one of neglect rather than capability.
Remediation lives in the codebase and is handled by the front-end engineering team, typically as focused pull requests rather than a rebuild. The highest-value fixes are a client component in the root layout that moves focus to main on every route change, role="status" live regions for server-action results, and enforcing alt props and lint rules via eslint-plugin-jsx-a11y. Scan the production build with next start rather than the dev server, and wire an automated a11y check into CI so regressions are caught before merge.
Top WCAG failures we see on Next.js sites
Across hundreds of Next.js scans, the same handful of issues show up over and over. None of them require ripping the theme apart — most are fixable in a few hours by someone comfortable in the platform's editor or template files.
Focus is lost on client-side route changes
next/link and useRouter().push() do not move focus to the new page's main heading. Screen-reader users hear nothing on navigation.
2.4.3 Focus Order, 4.1.3 Status Messages — Level A/AADynamic imports drop landmarks
Components loaded via next/dynamic with ssr:false render after hydration; if they contain <main> or <nav>, page structure is briefly missing for assistive tech.
1.3.1 — Level Anext/image without alt props
Required-by-types but trivially set to empty string; many teams ship "" alt for content images, hiding them from screen readers entirely.
1.1.1 — Level AForm actions without ARIA live announcements
Server actions and useActionState successes/failures often update silently. Without role="status", users do not learn the form succeeded.
4.1.3 — Level AA
Concrete code fixes for Next.js
Below are copy-paste fixes for the most common Next.js issues. They assume you have access to your theme code or the platform's custom-code injection panel. If you cannot edit code directly, share these snippets with whoever maintains the site — every one of them is a ten-minute change.
Move focus to <main> on every route change
'use client';
import { useEffect } from 'react';
import { usePathname } from 'next/navigation';
export function FocusOnRouteChange() {
const pathname = usePathname();
useEffect(() => {
const main = document.querySelector('main');
if (main instanceof HTMLElement) {
main.setAttribute('tabindex', '-1');
main.focus();
}
}, [pathname]);
return null;
}Drop into your root layout. After every navigation, focus lands on <main>, restoring screen-reader context.
Form: announce server-action results
'use client';
import { useActionState } from 'react';
export function ContactForm({ action }: { action: any }) {
const [state, formAction] = useActionState(action, { ok: false, msg: '' });
return (
<form action={formAction}>
{/* ... fields ... */}
<p role="status" aria-live="polite">{state.msg}</p>
</form>
);
}role="status" makes assistive tech announce the action result without stealing focus.
Tools and plugins worth installing first
eslint-plugin-jsx-a11y — catches missing alt, label, and role issues at lint time
next-axe / @axe-core/react in development to surface runtime issues
Certvo SSR scan reports the rendered HTML, not the source — catches hydration-only failures
How to scan a Next.js site without missing anything
Automated scanners catch about 30–40% of WCAG issues; the rest need manual review. The good news is that the 30–40% includes the most expensive issues to remediate after the fact, so an automated scan is the cheapest way to get unstuck. Run one before you change a line of theme code.
Scan the production build (next start), not the dev server. Dev injects extra UI.
Crawl ISR pages with a fresh cache; first-request HTML can differ from steady state.
Run a free public scan against any Next.js URL right now — no signup, results in 60 seconds.
Frequently asked questions
Does Next.js help or hurt accessibility versus a plain React SPA?
Helps. SSR/SSG produces a meaningful initial HTML payload that crawlers and assistive tech see immediately. SPA frameworks without SSR render a near-empty page until JS loads.
Are Server Components automatically accessible?
Server Components do not change accessibility on their own — the rendered HTML is what matters. The benefit is that you can guarantee server-rendered landmarks before any client JS runs.
Other web framework platforms
EAA compliance for React
The most-used UI library; the foundation of Next.js, Remix, and most modern SPAs.
EAA compliance for Vue.js
Top 3 frontend framework; common in SMB and education sites across Europe.
EAA compliance for Angular
Enterprise default in many EU public-sector portals; subject to EAA and EN 301 549.
EAA compliance for Astro
Fast-growing meta-framework for content-heavy sites.
All EAA platform guides
Shopify, WordPress, Next.js, Webflow and more
Complete WCAG 2.1 guide
POUR principles, conformance levels, legal requirements
How-to fix recipes
Copy-paste fixes for the most common WCAG failures
Find every accessibility issue on your site in 60 seconds.
Free public scan. No card. AI-generated fixes for every issue we find.