EU Accessibility Act for Next.js Developers: The 2026 Compliance Guide

The EU Accessibility Act (EAA, Directive 2019/882) became enforceable on June 28, 2025. As of April 2026, the first round of enforcement letters has gone out. Companies that ship digital products to the EU and don't have an accessibility statement are receiving formal notices from member state regulators. Some have already paid fines.

If you build web products with Next.js and you sell anything to EU customers, this affects you. This guide explains exactly what the law requires, which Next.js patterns fail it, what it costs to fix, and how to produce the documentation you actually need to show regulators and procurement buyers.

This is not legal advice. It is a developer's working knowledge of the EAA based on shipping 14 WCAG-compliant Next.js apps and helping clients get procurement-ready. For binding legal interpretation, talk to a lawyer in the relevant member state.

Who is in scope

The EAA applies to private-sector products and services sold in the EU on or after June 28, 2025. The web-relevant scope:

Ecommerce websites and apps that sell physical or digital goods to consumers
Banking, payment, and financial services including consumer-facing fintech
Transport ticketing and information (airline, rail, urban transit)
Telecommunications customer-facing services
Audiovisual media services including streaming
E-books and dedicated e-reader apps

The scope is broader than people expect. If you sell a SaaS subscription to EU customers, you are in scope. If your product has any consumer-facing component (signup, login, billing, support, marketing site), the consumer-facing parts are in scope. If your product is B2B-only and never reaches a consumer, you are technically out of scope but most enterprise procurement teams will require compliance anyway.

Microenterprise exemption: companies with fewer than 10 employees AND less than €2 million annual turnover are exempt from the substantive requirements but still must provide information about accessibility on request. This exemption is narrow and you should not rely on it without legal advice.

What the law requires

The EAA is performance-based, not prescriptive. It tells you the goal (digital products must be accessible to people with disabilities) and gives you a "harmonized standard" that is presumed to satisfy the requirement: EN 301 549.

EN 301 549 incorporates WCAG 2.1 Level AA for web content. As of late 2025, the European Commission is updating EN 301 549 to incorporate WCAG 2.2 — expect that to land in 2026 or 2027.

In practice, if your Next.js app passes WCAG 2.1 Level AA, you are presumed compliant with the EAA for the web content portion. This is the same standard required under the US ADA case law and Section 508, so most accessibility work translates directly.

You also need:

An accessibility statement publicly available on your website
A way for users to report accessibility issues (a contact form or email)
A record of accessibility testing that you can produce on request
Compliance documentation for any procurement buyer that asks

What it does NOT require

A few things teams worry about that are not actually required:

Overlay widgets are not compliant. The accessibility overlay tools that promise instant compliance (you've seen the ads) are not compliant under the EAA. The European Disability Forum and several courts have stated explicitly that overlays do not satisfy the requirement and may even introduce new accessibility issues.
AAA conformance is not required. Level AA is the standard. AAA is aspirational and not required by the EAA.
Native mobile apps are in scope under a separate technical standard (also referenced in EN 301 549). This guide focuses on web; mobile is similar but has its own conformance criteria.
You do not need a third-party accessibility certification. A self-assessment with documentation is sufficient. Third-party audits help with procurement and dispute defense, but they are not legally required.

What it actually requires for a Next.js app

This is the part developers need. WCAG 2.1 AA has 50 success criteria. For a typical Next.js + Tailwind + shadcn/ui app, here are the ones that matter most and the patterns that fail them.

Color contrast (WCAG 1.4.3 and 1.4.11)

Requirement: 4.5:1 ratio for normal text, 3:1 for large text and UI components.

Common Next.js failure: Tailwind's default text-gray-500 on bg-white is 4.6:1 — barely passes. text-gray-400 is 2.8:1 — fails. shadcn's default text-muted-foreground is borderline in light mode, fine in dark.

Fix: test every text color against every background color you put it on. Use the TheFrontKit Color Palette Validator to check entire themes at once. For single colors, use the Color Contrast Checker.

Focus visibility (WCAG 2.4.7 and 1.4.11)

Requirement: keyboard focus must be visible with at least 3:1 contrast against the background.

Common Next.js failure: shadcn's default focus-visible:ring-ring/50 renders the ring at 50% opacity, which is below 3:1 in most light themes. We covered this in detail in the shadcn/ui audit.

Fix: use ring-2 ring-ring ring-offset-2 ring-offset-background instead. Test in both light and dark mode.

Keyboard accessibility (WCAG 2.1.1 and 2.1.2)

Requirement: every interactive element must be reachable and operable with the keyboard alone.

Common Next.js failure: clickable <div> with onClick. Modal that doesn't trap focus. Custom dropdown that doesn't support arrow keys.

Fix: use <button>, <a>, or <Link> for clickable elements. Use shadcn's Dialog (built on Radix) for modals. Use shadcn's Select, Combobox, or DropdownMenu for selectable options. The Radix primitives handle keyboard correctly.

Form labels (WCAG 3.3.2)

Requirement: every form input must have a programmatically associated label.

Common Next.js failure: Input with placeholder but no label. Input wrapped in a <div> containing the label text but no htmlFor association. AI-generated forms that use aria-label inconsistently.

Fix: use shadcn's <Label> component with htmlFor matching the input's id. The shadcn <Form> component (built on react-hook-form) handles this automatically when you use <FormField> and <FormLabel>.

Heading structure (WCAG 1.3.1 and 2.4.6)

Requirement: one <h1> per page, no skipped heading levels.

Common Next.js failure: Marketing pages with multiple <h1> elements. Dashboard pages that jump from h1 to h3 because h2 looked too big.

Fix: outline your page structure before writing JSX. The page title is h1. Top-level sections are h2. Subsections are h3. If you need a smaller-looking heading, use CSS, not a smaller heading level.

Alt text on images (WCAG 1.1.1)

Requirement: every meaningful image must have alternative text. Decorative images use alt="".

Common Next.js failure: <Image> from next/image with no alt. Hero illustrations marked alt="hero illustration" (not informative). Logos labeled alt="logo" (use the company name).

Fix: every <Image> and <img> gets a meaningful alt describing what the image conveys, OR alt="" if it's purely decorative. The Next.js linter will warn if alt is missing entirely; configure ESLint to enforce it.

Link purpose (WCAG 2.4.4)

Requirement: link text must describe where the link goes.

Common Next.js failure: "Click here" and "Read more" links that don't make sense out of context.

Fix: rewrite links to be self-describing. "Read more" becomes "Read more about WCAG 2.2 AA". "Click here" becomes "View pricing". This also helps SEO.

Status messages (WCAG 4.1.3)

Requirement: status messages (success, error, loading) must be announced to screen readers without taking focus.

Common Next.js failure: Toast notification that appears visually but is not in a role="status" or aria-live region. Form error messages that appear silently.

Fix: use sonner (the toast library shadcn ships with) — it handles this correctly. For form errors, ensure the error message has an id and the input has aria-describedby pointing to it.

Reflow (WCAG 1.4.10)

Requirement: content must reflow to 320 CSS pixels wide without horizontal scrolling.

Common Next.js failure: dashboards with fixed-width data tables that overflow on mobile. Hero sections with min-w-[800px].

Fix: use responsive utilities (overflow-x-auto on table containers, flex-col md:flex-row on layouts). Test every page at 320px.

Touch target size (WCAG 2.5.8 — new in 2.2)

Requirement: interactive targets must be at least 24x24 CSS pixels (44x44 strongly recommended).

Common Next.js failure: icon buttons sized size-6 (24px), close buttons at size-4 (16px), carousel dots at 8px.

Fix: use size-11 (44px) for tap targets. For visually small elements like dots, wrap them in an invisible 44px hit area:

<button className="flex items-center justify-center size-11" aria-label={`Go to slide ${i + 1}`}>
  <span className="size-2 rounded-full bg-primary" />
</button>

What it costs to fix

Based on real client engagements, here's what remediation typically costs for a Next.js app:

App size	Audit time	Remediation time	Total cost (in-house)	Total cost (consultant)
Marketing site (5-10 pages)	4 hours	8-16 hours	1-2 dev days	$1,500-$3,000
Small SaaS (15-30 screens)	8 hours	24-40 hours	4-7 dev days	$5,000-$10,000
Mid-size dashboard (40-80 screens)	16 hours	60-120 hours	10-20 dev days	$15,000-$30,000
Large platform (100+ screens)	40 hours	200+ hours	30-50 dev days	$40,000+

These numbers assume the app was built with Next.js + shadcn/ui (which gets you most of the way there). Apps built on custom design systems or older React patterns typically take 2-3x longer to remediate because more components have to be replaced rather than patched.

The cheapest fix is to build it right the first time. The second cheapest is to remediate before launch. The most expensive is to remediate after a procurement buyer or regulator forces it, because that path also includes legal review, customer communication, and possibly emergency engineering hours.

We do remediation engagements for $2,990 to $5,990 depending on scope. That's the consultant pricing in the table above for a typical SaaS or dashboard app.

How to write the accessibility statement

The EAA requires an accessibility statement on your website. Here's the structure that satisfies the requirement and reads cleanly to a procurement buyer.

## Accessibility Statement for [Company Name]

[Company Name] is committed to ensuring digital accessibility for people
with disabilities. We are continually improving the user experience for
everyone and applying the relevant accessibility standards.

### Conformance status

[Product Name] is partially conformant with WCAG 2.1 Level AA.
"Partially conformant" means that some parts of the content do not fully
conform to the accessibility standard. [Or "fully conformant" if you've
verified everything passes.]

### Compatibility

[Product Name] is designed to be compatible with the following assistive
technologies:
- Latest versions of Chrome, Firefox, Safari, and Edge
- VoiceOver on macOS and iOS
- NVDA on Windows
- TalkBack on Android

### Technical specifications

[Product Name] relies on the following technologies for accessibility:
- HTML
- CSS
- JavaScript
- ARIA
- Next.js, React, and Tailwind CSS

### Limitations and alternatives

Despite our best efforts, some content may have minor accessibility
limitations:
- [Honest list, e.g.: "Some legacy charts do not include text alternatives.
  We are addressing this in our next release."]

### Feedback

We welcome your feedback on the accessibility of [Product Name]. Please
contact us if you encounter accessibility barriers:
- Email: accessibility@yourcompany.com
- Phone: [optional]
- Postal address: [optional]

We aim to respond to feedback within 5 business days.

### Assessment approach

[Company Name] assessed the accessibility of [Product Name] by the
following approaches:
- Self-evaluation against WCAG 2.1 Level AA
- Automated testing with axe-core
- Manual testing with keyboard and screen reader
- [Optional: third-party audit by [auditor name] on [date]]

### Date

This statement was created on [date] using the [methodology].
Last reviewed: [date].

You can put this at /accessibility on your domain. Link to it from your footer. Update the "last reviewed" date when you do an audit pass.

What to do this week

If you haven't started, here's the prioritized list:

Run an automated scan. Use the free TheFrontKit accessibility checker on your top 5 pages. This catches 30-40% of issues in 5 minutes and gives you a baseline.
Run the WCAG 2.2 checklist on the same 5 pages to catch the things automated tools miss.
Publish an accessibility statement at /accessibility using the template above. Even if your product isn't fully compliant yet, having a statement that honestly describes the current state is better than having nothing. The EAA explicitly allows "partial conformance" with a remediation plan.
Add accessibility@yourcompany.com as a real email address that someone monitors. The EAA requires you to have a way for users to report issues.
Document what testing you've done. Even an internal Notion page is fine. If a regulator or buyer asks "how do you know your product is accessible," you need an answer.
Plan the remediation work. Use the cost table above to scope the engineering effort. Build it into your roadmap as a real project, not a side task.
For procurement-critical apps, consider a third-party audit. TheFrontKit accessibility audits start at $499 for a quick scan, $1,490 for a procurement-ready report, and $5,990 for full remediation.

What enforcement actually looks like

As of April 2026, here's the enforcement pattern across EU member states:

Germany, Netherlands, France, and Ireland have active enforcement programs. Letters have gone out to companies operating without an accessibility statement.
Initial enforcement is corrective, not punitive. Most letters give 60-90 days to publish a statement and a remediation plan.
Fines apply for non-response. Member state laws vary, but fines start in the €10,000 range and can scale with company size.
Class-action and individual complaints are allowed under several member state implementations. The first private suits are working their way through court in 2026.
Procurement is the bigger driver right now. Most enterprise EU buyers now require accessibility statements as part of vendor onboarding. No statement, no sale.

The legal risk is real but not yet catastrophic. The procurement risk is here today. If you sell to EU enterprise customers, you're already losing deals if you can't produce an accessibility statement during procurement.

A quick word on US readers

If you're a US-based developer and you skipped this post because you don't sell to the EU: you should still read it. The same WCAG 2.1 AA standard is what US courts use to evaluate ADA compliance for websites. Title III ADA cases against websites have been climbing every year — over 4,000 federal lawsuits in 2024. The standard the courts apply is essentially identical.

If your product is sold anywhere in North America or Europe, WCAG 2.1 AA is the practical legal floor.

Tools and resources

Free tools we built specifically for this:

Free PDF Accessibility Checker — for accessibility statements and compliance docs
Free Interactive WCAG 2.2 Checklist — track your compliance work
Free ARIA Validator — catch the AI-generated mistakes
Free Color Palette Validator — for theme contrast
Free Color Contrast Checker for Tailwind
Free Website Accessibility Checker

External resources:

If you need help

We run accessibility audits and remediation specifically for Next.js and React apps. We've shipped 14 WCAG AA compliant Next.js kits ourselves and we know what procurement buyers and regulators look for. Pricing starts at $499 for a Starter Audit and goes to $5,990 for full remediation. Most engagements take 5-21 days and produce a procurement-ready PDF deliverable.

The EAA is enforceable now. Procurement buyers are asking for compliance now. The earlier you get this in order, the cheaper it is.