European Accessibility Act 2026: Complete SaaS Developer Guide

Post #1 in the sota.io EU-EAA-DEVELOPER-2026 Series

The European Accessibility Act (EAA) — Directive (EU) 2019/882 — has been in force since June 28, 2025. One year into the application period, enforcement is ramping up across EU member states, and many SaaS companies are discovering they're in scope without realising it.

This guide cuts through the complexity: which digital services fall under the EAA, what the technical requirements actually mean in practice, and what you need to implement before an NCA comes knocking.

What Is the European Accessibility Act?

The EAA is a horizontal directive that harmonises accessibility requirements for a specific set of products and services across all 27 EU member states. Before the EAA, accessibility law was fragmented — Germany had the BFSG, France had the RGAA, the Netherlands had their own standards. The EAA creates a single EU-wide floor.

Key dates:

• June 28, 2019: Directive published in the Official Journal
• June 28, 2022: Member state transposition deadline
• June 28, 2025: Application date (requirements enforceable from this date)
• June 28, 2030: Legacy service contracts signed before June 28, 2025 must be updated by this date

Which SaaS Services Are In Scope?

The EAA does not cover all websites or software. It targets specific product and service categories defined in the Directive. For SaaS developers, the relevant categories are:

In-Scope Service Categories

Critical Question: Is Your SaaS In Scope?

For most B2B SaaS, the answer is "no" — the EAA primarily targets consumer-facing services. But several edge cases matter:

• B2B2C platforms: If your SaaS powers a customer-facing shop or banking portal, your downstream service provider is obligated — and they'll contractually push requirements up to you.
• Freemium products with consumer tier: A developer tool with a consumer free tier that includes checkout is in scope.
• Financial services SaaS: Any SaaS providing payment processing, account management, or investment services to consumers is in scope regardless of technical B2B framing.
• Communication platforms: Messaging SDKs, video call integrations, or hosted communication services accessible to end users.

If you're uncertain, the test is: does a consumer interact directly with your service to access banking, e-commerce, or communications? If yes, you're likely in scope.

The SME Exemption

The EAA includes a microenterprise exemption for service providers. Companies that meet ALL of the following criteria are exempt from accessibility requirements for services:

• Fewer than 10 employees, AND
• Annual turnover ≤ €2 million, OR annual balance sheet ≤ €2 million

Important: This exemption applies to service providers only. Manufacturers of products (hardware, embedded software) are not exempt regardless of size.

Additionally, any service provider — including large enterprises — can invoke the disproportionate burden clause if making a specific accessibility feature compliant would fundamentally alter the service or impose a disproportionate economic burden. This requires documented assessment and cannot be used as a blanket opt-out.

Technical Requirements: EN 301 549 v3.2.1

The EAA itself defines functional accessibility requirements in Annex I. The technical means of meeting those requirements is provided by the harmonised standard EN 301 549 v3.2.1 — the European standard for ICT accessibility.

EN 301 549 v3.2.1 incorporates WCAG 2.1 Level AA as its web content accessibility requirements. If your service passes WCAG 2.1 AA, you meet the web content portion of EN 301 549.

What WCAG 2.1 AA Actually Requires

WCAG 2.1 is organised around four principles (POUR):

1. Perceivable

• All non-text content (images, icons, charts) must have text alternatives (alt text, aria-label)
• Videos must have captions; audio must have transcripts
• Content must not rely solely on colour to convey information
• Minimum contrast ratio: 4.5:1 for normal text, 3:1 for large text
• Users must be able to resize text to 200% without losing content
• No content flashes more than 3 times per second (seizure risk)

2. Operable

• All functionality is available via keyboard navigation (no mouse traps)
• Skip navigation links for keyboard users
• No time limits that can't be paused/extended (or accessible alternatives)
• Users can control motion and animation (respects prefers-reduced-motion)
• Focus indicators are visible and have sufficient contrast

3. Understandable

• Language of the page is declared in HTML lang attribute
• Error identification and suggestions for form inputs
• Input purpose for personal data fields (autocomplete attributes)
• No unexpected context changes on focus or input

4. Robust

• Valid, parseable HTML (no duplicate IDs, proper nesting)
• Status messages (live regions) for dynamic content updates
• Name, role, value for all UI components (ARIA attributes)

Beyond WCAG: EN 301 549 Additions

EN 301 549 adds requirements beyond WCAG 2.1 that apply to software (not just web content):

• Documentation and support: Accessibility features must be documented; support services must be accessible
• Two-way voice communication: Real-time text (RTT) support for audio calls (relevant for communication services)
• Closed captions: For live audio and audiovisual content
• Audio description: For pre-recorded video content

For most web-based SaaS, the WCAG 2.1 AA requirements dominate. The additional EN 301 549 requirements primarily affect native mobile apps, desktop software, and communication services.

Obligations for Service Providers

In-scope service providers have four main obligations under the EAA:

1. Meet the Accessibility Requirements

Your service must meet the technical requirements in Annex I of the Directive, implemented via EN 301 549 v3.2.1. This is the core obligation.

2. Provide an Accessibility Statement

Service providers must publish an accessibility statement that explains:

• The level of conformance achieved (WCAG 2.1 A, AA, or non-conformant areas)
• Which parts of the service are not accessible and why
• Alternatives for inaccessible features
• Contact information for the feedback mechanism

The statement must be in a clear, simple accessible format. Most implementations publish it at /accessibility or link it from the footer.

3. Provide a Feedback Mechanism

Users must have a way to report accessibility problems and request accessible alternatives for content they cannot access. This doesn't need to be complex — an email address or contact form specifically for accessibility issues suffices.

4. Non-Conformance Assessment (Not Mandatory, But Recommended)

Unlike some other EU regulations, the EAA does not mandate third-party conformity assessment for service providers. Companies self-assess. However, market surveillance authorities can audit your service, so a documented internal assessment is strongly advisable.

What a Practical Implementation Looks Like

Here's a phased implementation approach for an in-scope SaaS product:

Phase 1: Scope and Audit (2-4 weeks)

1. Confirm your service category and in-scope user journeys
2. Run automated scan (axe DevTools, WAVE, Lighthouse accessibility audit)
3. Manual keyboard navigation test of all critical paths
4. Screen reader test (NVDA + Firefox, VoiceOver + Safari)
5. Document findings by WCAG criterion
6. Prioritise by user impact and effort

Automated scans catch roughly 30-40% of WCAG failures. Manual testing is required for the remainder.

Phase 2: Fix Critical Issues (4-8 weeks)

Priority order for typical SaaS products:

1. Missing alt text on images and icons
2. Form labels and error identification
3. Colour contrast failures
4. Keyboard trap bugs (modal dialogs, date pickers, dropdowns)
5. Missing focus indicators
6. Dynamic content without live region announcements

Phase 3: Accessibility Statement and Feedback Mechanism (1 week)

Publish your accessibility statement. A minimal compliant statement includes:

<!-- /accessibility page -->
<h1>Accessibility Statement</h1>
<p>This statement applies to [product name] at [URL].</p>
<p>We aim to meet WCAG 2.1 Level AA (EN 301 549 v3.2.1).</p>
<h2>Conformance Status</h2>
<p>Partially conformant: some parts do not fully meet all requirements.</p>
<h2>Known Issues</h2>
<ul>
  <li>[Issue 1]: [Brief description] — [Alternative/workaround]</li>
</ul>
<h2>Feedback</h2>
<p>Report accessibility problems: <a href="mailto:accessibility@example.com">
  accessibility@example.com
</a></p>
<p>We aim to respond within 5 working days.</p>
<h2>Assessment</h2>
<p>Self-assessed. Last reviewed: [Date].</p>

Phase 4: Ongoing Monitoring

Accessibility degrades with every deploy unless it's integrated into development workflow:

// package.json scripts
{
  "scripts": {
    "test:a11y": "jest --testPathPattern=accessibility",
    "audit:a11y": "axe-cli https://localhost:3000 --tags wcag2aa"
  }
}

Recommended toolchain:

• axe-core + jest-axe: Automated accessibility tests in CI
• Playwright + axe: End-to-end accessibility regression tests
• Storybook a11y addon: Component-level accessibility testing
• eslint-plugin-jsx-a11y: Lint-time accessibility checks for React

Current Enforcement Landscape (June 2026)

Enforcement is carried out by national market surveillance authorities (MSAs). The approach varies significantly by member state:

Germany

The Bundesfachstelle Barrierefreiheit (BFB) coordinates enforcement alongside Länder authorities. The implementation law is the Barrierefreiheitsstärkungsgesetz (BFSG), which transposed the EAA with effect from June 28, 2025.

The BFSG enforcement approach for the first period (2025-2026) has been primarily complaint-driven and education-focused, with formal enforcement expected to increase. Fines under the BFSG can reach €100,000 for systematic violations.

France

The Direction interministérielle du numérique (DINUM) manages accessibility policy, with the Autorité de régulation de la communication audiovisuelle et numérique (ARCOM) having enforcement powers for audio-visual services. France's RGAA (Référentiel Général d'Amélioration de l'Accessibilité) has been mapped to EN 301 549. French law requires an accessibility statement and rates services as compliant, partially compliant, or non-compliant.

Netherlands

The Rijksoverheid (central government) and sectoral regulators handle enforcement. Dutch transposition created obligations with graduated enforcement starting from June 28, 2025. The Netherlands had a relatively mature accessibility culture pre-EAA, with many larger providers already meeting requirements.

Practical Enforcement Risk Assessment

For most SaaS providers in June 2026:

• Complaint-driven is the dominant model: authorities investigate after user complaints
• Proactive audits are beginning but primarily targeting large platforms and public-facing financial services
• Cross-border enforcement cooperation is still developing — your primary risk is in your largest user markets

The credible enforcement risk in 2026 is not massive fines but rather:

1. A complaint triggers an MSA inquiry
2. MSA requests your accessibility statement and conformance evidence
3. If you have no statement and no documented assessment, you face a formal order to comply
4. Repeat violations or deliberate non-compliance carry financial penalties

Having an accessibility statement with an honest assessment of known issues is meaningful protection — it demonstrates good-faith compliance effort.

The Regulatory Relationship: EAA vs. Other EU Laws

The EAA intersects with several other regulations in your compliance stack:

• GDPR: Accessibility forms and feedback mechanisms collect personal data — ensure your privacy notice covers this. Screen-reader-accessible cookie consent UI is both a GDPR and EAA requirement.
• AI Act (Art.5/50): AI-powered features in in-scope services must be both AI Act compliant AND accessible. AI-generated content labeling (Art.50) must itself be accessible.
• DSA: For very large online platforms, DSA's transparency obligations and user interface requirements overlap with accessibility — an inaccessible terms-of-service UI could simultaneously violate DSA and EAA.
• Web Accessibility Directive (WAD, 2016/2102): This older directive covers public sector websites only. The EAA extends to private sector services. If you supply services to public bodies, both may apply.

The Series: What Comes Next

This is Post #1 of our 5-part EU-EAA-DEVELOPER-2026 series. Coming up:

• Post #2: EAA Technical Requirements Deep-Dive: EN 301 549 v3.2.1 Implementation Guide for Web Apps (Testing, ARIA Patterns, React/Next.js)
• Post #3: EAA Audit & Documentation 2026: Conformity Assessment, Accessibility Statement Templates & Audit Tools
• Post #4: EAA vs WCAG 2.1 vs EN 301 549: Which Standard Actually Applies and Where They Diverge
• Post #5: EAA Enforcement 2026 Finale: Country-by-Country Penalty Framework, Supervisory Authority Contacts & Compliance Checklist

10-Point EAA Readiness Checklist

Conclusion

The EAA is now live and enforced. The compliance baseline is manageable — WCAG 2.1 Level AA is well-understood, tooling is mature, and the main obligation for service providers is documented self-assessment plus an accessibility statement.

The real risk for SaaS developers is treating accessibility as a one-time project. Every new feature that adds an inaccessible component or removes keyboard navigability is a compliance regression. Build it into your development workflow now, and the ongoing cost is low.

Post #2 will go deep on the technical implementation: ARIA patterns, focus management, React/Next.js-specific accessibility patterns, and how to structure your test suite for EN 301 549 conformance.

Part of the sota.io EU-EAA-DEVELOPER-2026 series. View all EU compliance guides →