To comply with the European Accessibility Act (EAA), your web and mobile products must meet EN 301 549, the harmonised European standard the EAA is measured against — today that means WCAG 2.1 Level AA plus EN 301 549's non-web and mobile clauses, and once EN 301 549 v4.1.1 is harmonised (expected around October 2026), a WCAG 2.2 Level AA baseline. Compliance comes from fixing the source of your product — components, design tokens, focus behaviour, form semantics, native mobile accessibility APIs — not from installing an overlay widget. The program: audit against EN 301 549 clauses, remediate at the design-system layer so fixes propagate, enforce the result with CI tests plus manual assistive-technology testing, and publish a conformance report and accessibility statement.

Is EAA Enforcement Actually Happening, or Is 2026 Still a Grace Period?

Enforcement is real. The EAA became applicable on 28 June 2025, and within days French disability advocacy organisations issued formal legal notices (mises en demeure) to four major grocery retailers — Auchan, Carrefour, E. Leclerc and Picard — over inaccessible e-commerce platforms; emergency injunctions followed in November 2025 (Deque; Lainey Feingold Law). Sweden's PTS opened its first market-surveillance inspections in October 2025.

Penalties are set per member state, so exposure depends on where you sell — reported maxima range from roughly €60,000 in Ireland and €100,000 per violation in Germany to €300,000 per violation in France (Level Access). In practice, the bigger near-term risks are injunctions forcing a rushed rebuild, procurement disqualification, and findings surfacing in due diligence.

What Is the Difference Between WCAG 2.1 and WCAG 2.2 for EAA Compliance?

WCAG 2.2 is backwards-compatible with 2.1 and adds nine success criteria, six at Level A or AA — these land inside the EAA-relevant baseline once EN 301 549 v4.1.1 is harmonised:

Source: W3C, WCAG 2.2 Recommendation. Four of the six break in product code rather than content — drag-only interactions, sticky-UI focus obscuring, dense tap targets, and auth flows that block paste — exactly what a marketing-site audit misses.

Do Accessibility Overlays Satisfy EN 301 549?

No. Overlays inject JavaScript at runtime to patch the DOM, but conformance is judged on the delivered experience across assistive technologies, browsers and platforms — including native apps and PDFs an overlay never touches. An overlay can't infer meaningful alt text, restructure a heading hierarchy that carries no semantics, or repair a custom widget with no keyboard model.

The technical case is documented in the Overlay Fact Sheet, signed by hundreds of accessibility practitioners including WCAG, ARIA and HTML spec contributors. Legally: ADP's 2021 settlement with LightHouse for the Blind required removing its overlay and pursuing genuine WCAG 2.1 remediation instead.

How Do You Remediate at the Design-System Level Instead of Page by Page?

Page-by-page remediation doesn't scale and regresses within a release cycle. The high-leverage sequence:

1. Fix tokens before components. Low-contrast text is the single most common defect on the web — present on 83.9% of the top one million home pages (WebAIM Million 2026) — and it's almost always a token problem. Audit your palette for 4.5:1 body text / 3:1 large text (WCAG 1.4.3, 1.4.11), fix the token values once, and thousands of instances resolve. Do the same for focus-ring tokens and forbid outline: none via lint.

2. Rebuild the ten highest-risk components. Text input + label + error, select/combobox, modal, dropdown menu, tabs, accordion, toast, data table, date picker, file upload. Build these against WAI-ARIA Authoring Practices keyboard models — use native elements first (<button>, <dialog>, <input>), never an interactive handler on a <div>.

3. Get focus management right in the shell. After SPA route changes, move focus to the new page's <h1> and announce via a polite live region. Modals must trap focus, close on Escape, and return focus to the trigger — fixed once at the application-shell level.

4. Fix forms semantically. Missing form labels appear on 51% of home pages (WebAIM Million 2026). Every control needs a programmatic label; errors need aria-describedby plus text, not colour alone.

5. Treat mobile as a separate work stream. EN 301 549 has clauses beyond WCAG for native software: contentDescription/accessibilityLabel on every actionable element, correct focus order for TalkBack/VoiceOver, honouring OS dynamic type. A React Native or Flutter wrapper doesn't inherit web fixes.

How Do You Stop Accessibility Regressions With CI Testing?

Automate the reproducible layer, then reserve human effort for what tooling can't judge. Deque's analysis of 13,000+ audited pages found automated testing fully covered an average of 57% of accessibility issues by volume (Deque) — substantial, not a compliance guarantee.

• Unit layer: jest-axe/vitest-axe on every component in your library, run per PR.
• E2E layer: @axe-core/playwright on top journeys — signup, checkout, account settings — including mid-flow states like open modals and populated error summaries, which most scanners never reach.
• Baseline, then ratchet: snapshot current violations, fail the build on new ones, burn down the baseline on a schedule. Zero-tolerance gates on a legacy codebase get disabled within a week.
• Manual, quarterly and pre-release: keyboard-only pass, NVDA/JAWS, VoiceOver, TalkBack, 200% zoom. Content-quality criteria — meaningful alt text, error clarity — stay human judgement calls permanently.

What Goes Into an Accessibility Statement and Conformance Report That Holds Up?

The EAA expects in-scope operators to document conformity, and acquirers increasingly ask for the artefacts.

A conformance report should follow the EN 301 549 / ETSI Annex A clause structure — ideally an EU-format ACR/VPAT 2.x — recording, per clause, Supports / Partially Supports / Does Not Support / Not Applicable with a remark, plus scope, test environment, methodology, evaluator and date. Auditors distrust blanket "Supports" claims with no remarks.

A public accessibility statement states the conformance target, known non-conformances with fix dates, a feedback mechanism with response-time commitment, and the date of last review. Publish it at a stable URL and review it every release — a statement dated two years ago is itself a finding.

What Does a Realistic Remediation Timeline Look Like?

For a mid-sized SaaS or e-commerce product, budget roughly 90 days to a defensible position, not perfection:

• Weeks 1–3: Scope in-scope surfaces, run an expert audit on 10–15 page templates and 5 core journeys mapped to EN 301 549 clauses, output a defect register.
• Weeks 4–8: Token and design-system remediation, the ten high-risk components, focus management, forms and checkout. Wire up axe in CI with a frozen baseline.
• Weeks 9–12: Mobile-native pass, AT-based manual verification, third-party/vendor component triage (payment iframes, chat widgets, consent banners fail often), then produce the ACR and publish the statement.

The two things that most often derail the plan: third-party embeds you don't control, and design decisions needing product sign-off, not just engineering time. Start both conversations in week one. This cross-cutting work — design system, front end, native mobile, CI pipeline — is where an experienced engineering partner shortens the path, but the playbook above stands on its own regardless of who executes it.

FAQ

Does the European Accessibility Act apply to B2B SaaS companies?

The EAA targets products and services offered to consumers in the EU — e-commerce, banking, e-books, transport, telecoms. Pure B2B software is generally outside direct scope, but captured indirectly: your enterprise customers in scope must procure accessible tooling, and public-sector buyers are already bound by the Web Accessibility Directive.

Is there a microenterprise exemption under the EAA?

Microenterprises providing services — fewer than 10 employees, turnover or balance sheet under €2 million — are exempt from the EAA's service obligations. The exemption doesn't cover microenterprises that manufacture, import or distribute in-scope products, and thresholds are assessed against national implementing law. Confirm your position with counsel in each member state where you sell.

Do I need WCAG 2.2 now, or is WCAG 2.1 AA still enough?

The currently harmonised standard is EN 301 549 v3.2.1, incorporating WCAG 2.1 Level AA — that remains the operative benchmark today. EN 301 549 v4.1.1, expected around October 2026, raises the baseline to WCAG 2.2 Level AA. Since the new A/AA criteria are cheap to build in and expensive to retrofit, target WCAG 2.2 AA in any remediation work starting now.

Will an accessibility overlay or widget protect us from EAA penalties?

No. Overlays can't deliver conformance with EN 301 549 clauses that depend on underlying semantics, keyboard operability, or native mobile APIs, and the Overlay Fact Sheet — signed by WCAG, ARIA and HTML spec contributors — documents why. Regulators assess the actual user experience, not the presence of a widget.

How much of WCAG can automated testing actually catch?

Deque's study across 13,000+ audited pages found automated tooling completely covered about 57% of accessibility issues by volume. Automation reliably catches contrast, missing labels, and ARIA misuse; it can't judge whether alt text is meaningful or a keyboard order makes sense — budget for manual assistive-technology testing every release.

What evidence should we keep to prove EAA compliance if we are challenged?

Keep a versioned EN 301 549-structured conformance report (ACR/VPAT) with test dates and evaluator names; your published accessibility statement with dated fix commitments; CI run history showing accessibility gates on merges; and a defect register with remediation timestamps. Documented, dated, continuous effort is what distinguishes a good-faith compliance program from a claim.