TL;DR: The European Accessibility Act (EAA) comes into force on 28 June 2025 and requires most consumer-facing websites and apps sold into the EU to meet WCAG 2.1 AA as their technical baseline. Fines vary by member state but can reach six figures. If you are running a Next.js or Astro site, there is a clear, testable checklist you can work through today -- and if you are still on a legacy CMS like WordPress or Wix, this deadline is probably the forcing function you needed to rebuild properly.

What exactly is the EU Accessibility Act and who does it cover?

The European Accessibility Act (Directive 2019/882) was adopted in 2019 and must be transposed into national law across all 27 member states by 28 June 2025. After that date, enforcement begins. The directive covers a wide range of products and services including e-commerce websites, banking services, e-books, transport ticketing, and consumer electronics. If your business sells services to EU consumers online, you are almost certainly in scope.

The EAA borrows its technical requirements from EN 301 549, the European standard that itself references WCAG 2.1 at level AA as the benchmark for web content. So practically speaking, WCAG 2.1 AA is the floor.

Micro-enterprises -- defined as businesses with fewer than 10 employees AND annual turnover or balance sheet below 2 million euros -- are formally exempted from the service provisions of the directive. But that exemption is narrower than most founders assume. The moment your SaaS or e-commerce business crosses either threshold, you are in.

Penalties are set at member-state level. Germany's transposing legislation, the Barrierefreiheitsstärkungsgesetz (BFSG), allows fines of up to 100,000 euros per infringement. France and the Netherlands are drafting similar enforcement regimes. The reputational risk sits on top of the financial one.

What does WCAG 2.1 AA actually require in practice?

WCAG 2.1 AA is organised around four principles: Perceivable, Operable, Understandable, and Robust (POUR). At the AA tier there are 50 success criteria to satisfy. The ones that cause the most failures on real sites are worth naming explicitly.

Colour contrast. Normal text must have a contrast ratio of at least 4.5:1 against its background. Large text (18pt or 14pt bold) gets a 3:1 ratio. This fails on countless sites using light-grey body copy over white -- a very common design trend that is now legally problematic in the EU.

Keyboard navigation. Every interactive element must be reachable and operable without a mouse. This includes modals, dropdowns, carousels, and custom components. Focus must never be trapped (unless intentionally, like inside an open modal, where it must be releasable via Escape).

Images and non-text content. Every <img> that conveys information needs a descriptive alt attribute. Decorative images should have alt="" so screen readers skip them. SVG icons used as buttons need aria-label or a visually-hidden text alternative.

Form labels. Every input field must have a programmatic label associated via for/id or aria-labelledby. Placeholder text alone does not count as a label under WCAG 1.3.1.

Captions and transcripts. Pre-recorded video must have captions. Live video must have real-time captions. Audio-only content needs a text transcript.

Resize and reflow. Content must be readable at 400% zoom without horizontal scrolling (on a 1280px viewport). This catches sites where text truncates or overlaps at high zoom.

Error identification. When a form fails validation, the error must describe the problem in text -- not just turn the border red.

How do you audit a Next.js or Astro site before June 2025?

Start automated, then go manual. Automated tools like axe-core, Lighthouse, and WAVE catch roughly 30-40% of WCAG issues according to research by WebAIM. That is a useful baseline, not a certificate of compliance.

For Next.js, the most practical setup is installing @axe-core/react and eslint-plugin-jsx-a11y. The ESLint plugin catches issues at write time -- missing alt text, invalid ARIA roles, buttons missing accessible names. Add it to your .eslintrc and make the CI pipeline fail on accessibility errors, not just type errors.

npm install --save-dev eslint-plugin-jsx-a11y @axe-core/react

In your next.config.js you can also enable the built-in Next.js accessibility linting rules that ship with the framework's default ESLint config. They are not exhaustive but they remove the obvious low-hanging failures before code review.

For Astro, the story is similar. Astro's official docs recommend astro-eslint-parser combined with eslint-plugin-jsx-a11y for component-level linting. Because Astro ships zero JavaScript by default for static pages, keyboard-trap issues are less common -- but any island that hydrates (React, Svelte, Vue) needs the same scrutiny as a full client-rendered app.

After automated scanning, manual testing is non-negotiable. Keyboard-only browsing through your entire user journey. VoiceOver on macOS/iOS. NVDA on Windows. The WebAIM Screen Reader Survey shows NVDA and JAWS are the most-used screen readers on desktop; JAWS has a market share around 40% among desktop screen reader users. Test with both if budget allows.

How do you implement accessibility correctly in Next.js specifically?

Next.js gives you a good foundation but you still need to build on it deliberately.

Route announcements. When a user navigates between pages in a client-rendered Next.js app, screen readers do not automatically announce the new page title the way a full browser reload would. The next/link component alone does not solve this. You need a live region -- a visually-hidden <div aria-live="polite" aria-atomic="true"> that updates with the new page title on route change. You can hook into router.events in the Pages Router or use a usePathname effect in the App Router to trigger this update.

Focus management on navigation. After a route change, focus should move to a logical place -- usually a skip-nav link target or the main <h1>. Without this, keyboard users are left wherever they were before the navigation, which is disorienting. Libraries like next-focus-visible help but the core pattern needs to be in your layout.

Skip links. A "Skip to main content" link must be the first focusable element on every page. It should be visually hidden until focused, then become visible. This satisfies WCAG 2.4.1 Bypass Blocks. In Next.js, put it in your root layout component above everything else.

Document language. Your <html lang="en"> attribute matters. Screen readers use it to set the correct pronunciation engine. In Next.js App Router, set it in the RootLayout. In Pages Router, use next/head or _document.tsx. Do not leave it as the default empty string.

Color tokens and Tailwind. If you are using Tailwind CSS, the default palette has contrast failures at several shade combinations -- text-gray-400 on white is a common one at roughly 2.8:1. Use Tailwind's arbitrary values or a custom color token system checked against contrast requirements before design handoff. Tools like Accessible Palette let you build a full color scale where every semantic pairing is documented with its contrast ratio.

How do you implement accessibility correctly in Astro specifically?

Astro's architecture is actually advantageous here. Static HTML output means fewer client-side rendering edge cases. But there are Astro-specific patterns worth knowing.

Semantic HTML in .astro files. Because Astro components are essentially HTML templates, there is no excuse for using <div> when a <button> or <nav> is semantically correct. Use <main>, <header>, <footer>, <article>, and <aside> meaningfully. Landmark regions are free accessibility wins.

View Transitions. Astro's View Transitions API (stable since Astro 3.0) is a powerful feature for smooth page navigation but it carries an accessibility responsibility. When view transitions are enabled, the browser handles navigation in a non-traditional way, which can break focus management and live region announcements. Astro's accessibility guide for view transitions recommends respecting prefers-reduced-motion and ensuring focus is moved to the <main> element after each transition. Hook into the astro:page-load event to move focus programmatically.

Content collections and alt text enforcement. If you are using Astro's Content Collections for a blog or docs site, define a Zod schema that makes image.alt required rather than optional. This enforces alt text at the data layer, before a template can render a broken experience.

Islands and ARIA. Each interactive island (a React or Svelte component that hydrates) is its own accessibility scope. Test each island in isolation. Modal islands in particular need role="dialog", aria-modal="true", aria-labelledby pointing to the modal title, and a focus trap that releases on Escape.

Does rebuilding on Next.js or Astro make compliance easier than patching a legacy site?

Honestly, yes -- though I want to be specific about why rather than just claiming it categorically.

Legacy WordPress sites typically accumulate accessibility debt in three layers simultaneously: the theme, the page builder (Elementor, Divi, WPBakery), and third-party plugins. Each of those layers can introduce its own ARIA violations, contrast failures, and keyboard traps. Fixing them often means overriding plugin-generated markup you cannot fully control. We have worked with clients who spent months patching a WordPress site only to find a WooCommerce update broke the ARIA landmark structure again.

Wix and Squarespace are similarly constrained. You are limited to whatever accessibility features the platform exposes, and platform-level fixes depend entirely on the vendor's roadmap.

A rebuild in Next.js or Astro means you own every byte of HTML output. You can enforce accessibility at the linting, testing, and deployment stage. It also tends to produce cleaner Core Web Vitals, which matters for the SEO side of things -- a topic we spend a lot of time on at Social Animal.

That said, a rebuild is not always necessary or affordable by June 2025. If your existing site is built on a solid theme and you have control over the template layer, a targeted audit-and-fix campaign with automated regression testing can get you compliant. The key is honest assessment of whether you can actually control the output.

FAQ

When exactly does the EAA enforcement start?

28 June 2025. Member states were required to transpose the directive into national law and begin enforcement from that date. Some existing services have a transitional period -- service contracts concluded before 28 June 2025 may be exempt until 28 June 2030 -- but new services launched after the deadline must comply immediately. See Article 32 of Directive 2019/882 for the transitional provisions.

Does the EAA apply to UK businesses?

Not directly, since the UK left the EU. However, if you sell services to EU consumers, EU member-state regulators can act against you. The UK has its own Public Sector Bodies Accessibility Regulations and the Equality Act 2010 already creates obligations for reasonable adjustments, which courts have interpreted to include digital accessibility.

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 including Focus Appearance (2.4.11), Dragging Movements (2.5.7), and Target Size Minimum (2.5.8). The EAA currently references EN 301 549 v3.2.1, which maps to WCAG 2.1. However, EN 301 549 is being updated and WCAG 2.2 adoption is likely in the next revision. Building to WCAG 2.2 AA now is sensible future-proofing and the additional criteria are not technically burdensome.

Can an accessibility overlay widget make my site compliant?

No. Overlay widgets like AccessiBe and AudioEye have been publicly criticised by disability advocates and accessibility experts because they cannot fix underlying semantic HTML failures and can actually interfere with assistive technologies users already have configured. They do not satisfy EN 301 549 or WCAG 2.1 AA as a standalone solution. The Overlay Fact Sheet, signed by hundreds of accessibility professionals, makes this case clearly.

How do I prove compliance if a regulator asks?

Produce a Voluntary Product Accessibility Template (VPAT) or an Accessibility Conformance Report (ACR) documenting your WCAG 2.1 AA evaluation. Publish an accessibility statement on your site listing known issues, the standard you are targeting, and a contact method for users to report problems. The EAA requires this statement. It is also good practice to keep dated audit logs from automated tools and manual testing sessions, so you can demonstrate an ongoing compliance process rather than a one-time snapshot.