title: "European Accessibility Act 2025: SaaS Developer Compliance Guide — WCAG 2.2, API Accessibility & Enforcement Penalties" date: "2026-05-06" description: "The European Accessibility Act (EAA) has been enforceable since June 2025. This developer guide covers scope, WCAG 2.2 requirements for SaaS products, API accessibility obligations, conformance assessment, and penalties for non-compliance." tags: ["european-accessibility-act", "eaa", "wcag-2-2", "saas-compliance", "accessibility", "directive-2019-882", "eu-regulation", "developer-guide"]

European Accessibility Act 2025: SaaS Developer Compliance Guide

The European Accessibility Act (EAA), Directive 2019/882/EU, has been enforceable across EU member states since 28 June 2025. Unlike the Web Accessibility Directive (WAD) which covered only public-sector websites, the EAA reaches private-sector digital products and services — including SaaS platforms, e-commerce systems, banking apps, and the APIs that power them.

If your SaaS product serves EU customers and falls within EAA scope, you already have compliance obligations. Non-compliance exposes you to national enforcement actions, fines, and mandatory product withdrawal from the EU market.

This guide covers what EAA requires technically, who is in scope, how conformance is assessed, and what the penalties look like in practice.

1. EAA Legal Basis and Timeline

Directive 2019/882/EU was published in the Official Journal on 17 June 2019. Member states were required to:

• Transpose into national law by 28 June 2022
• Apply those laws from 28 June 2025 (enforcement start)

Key milestone for SaaS providers: The EAA applies to services from 28 June 2025. For products (hardware + software bundles), the same date applies for new products. Products already placed on the market before that date had a 5-year transition period expiring 28 June 2030.

2. Who Is In Scope

The EAA covers two categories: products and services. For SaaS developers, the services category is most relevant.

In-Scope Services (Article 2, Annex I Section V-VIII)

Critical threshold: The EAA applies to services provided to consumers in the EU. B2B-only SaaS platforms where end-users are exclusively business entities (not natural persons acting as consumers) are outside EAA scope — but the distinction must be genuinely maintained in your terms of service and technical access controls.

Microenterprise Exemption (Article 4(5))

Enterprises with fewer than 10 employees AND annual turnover/balance sheet ≤ €2 million are exempt from EAA requirements for services. However:

• Products (hardware+software bundles) do not get this exemption
• Subcontractors providing services to larger companies must comply even if they are microenterprises
• The exemption does not apply if the product/service is specifically designed to be provided to persons with disabilities

3. Technical Requirements: WCAG 2.2

The EAA mandates that in-scope digital services meet the functional accessibility requirements set out in Annex I. For web-based SaaS, the harmonised European standard EN 301 549 v3.2.1 (which incorporates WCAG 2.2) defines how to achieve compliance.

WCAG 2.2 Success Criteria for SaaS

WCAG 2.2 added three new criteria beyond WCAG 2.1 that are particularly relevant for SaaS applications:

SC 2.4.11 — Focus Not Obscured (Minimum) [AA]

When a keyboard-focusable component receives focus, the component must not be entirely hidden by author-created content (e.g., sticky headers, chat widgets). For SaaS dashboards with fixed navigation bars and floating action buttons, this requires active layout testing.

Implementation: Ensure z-index stacking and position: sticky elements never fully cover focused elements. Add scroll-padding-top to account for fixed header height.

SC 2.4.12 — Focus Not Obscured (Enhanced) [AAA]

The focused component must be fully visible. This is Level AAA (not mandatory for EAA Level AA conformance) but good practice.

SC 2.5.7 — Dragging Movements [AA]

Any functionality that requires dragging must also be achievable through a single pointer without dragging. This is critical for:

• Kanban boards (drag-to-reorder)
• File upload interfaces (drag-and-drop)
• Data visualization with drag-select
• Slider controls

Implementation: Every draggable interface element needs an alternative interaction path (keyboard, click-to-select, or explicit buttons).

SC 2.5.8 — Target Size (Minimum) [AA]

Interactive targets must be at least 24×24 CSS pixels with adequate spacing. This affects:

• Icon-only buttons in toolbars
• Close buttons on notifications
• Compact table row actions

/* Compliant button minimum */
.action-btn {
  min-width: 24px;
  min-height: 24px;
  /* Or: ensure 24px offset from adjacent targets */
}

SC 3.2.6 — Consistent Help [A]

If a help mechanism (chat, documentation link, contact form) appears on multiple pages, it must appear in the same relative location across those pages. For SaaS apps with inconsistent sidebar layouts, this requires a design audit.

SC 3.3.7 — Redundant Entry [A]

Information previously entered by the user must not be requested again in the same process unless re-entering is essential. This applies to multi-step forms and onboarding flows.

SC 3.3.8 — Accessible Authentication (Minimum) [AA]

Cognitive function tests (solving puzzles, remembering a code from one page to another) must not be the only means of authentication. For SaaS login flows:

• CAPTCHA must not be the sole authentication factor
• If cognitive tests are used, a text-based alternative must exist
• Copy-paste and password manager injection must be allowed

4. API Accessibility Obligations

This is the area most SaaS developers overlook. The EAA's Annex I explicitly requires that:

"Technical information needed for accessibility of products and services shall be available to manufacturers of hardware, software, electronic communications equipment..."

For SaaS platforms that expose APIs, this creates several obligations:

4.1 Programmatic Access to Accessibility State

If your SaaS product includes a UI component layer and an API, accessibility state must be accessible programmatically:

{
  "type": "input",
  "id": "email-field",
  "label": "Email address",
  "required": true,
  "validationState": "error",
  "errorMessage": "Please enter a valid email address",
  "ariaDescribedBy": "email-error-msg"
}

APIs that return UI component data must expose ARIA attributes, validation states, and labels in a way that assistive technology integration (screen readers, AAC devices) can consume.

4.2 Accessible Documentation

API documentation must itself be accessible. Swagger/OpenAPI documentation rendered in browsers must meet WCAG 2.2 Level AA:

• alt text for all diagrams
• Keyboard-navigable code examples
• Sufficient color contrast in syntax highlighting
• Accessible tables for endpoint parameter lists

4.3 Machine-Readable Accessibility Conformance

EN 301 549 Section 12.1.1 requires that accessibility documentation be available in formats processable by users and downstream integrators. For SaaS:

• Accessibility Conformance Report (ACR) using VPAT 2.x format
• Published at a persistent URL (e.g., https://yoursaas.io/accessibility)
• Updated when accessibility-relevant changes are deployed

5. Conformance Assessment Paths

The EAA allows two paths to demonstrate conformance:

5.1 Self-Declaration (Article 15)

Manufacturers and service providers can self-declare conformance using a Declaration of Conformance that includes:

1. Reference to the harmonised standard(s) applied (EN 301 549)
2. The conformance level achieved (Level AA)
3. Date of declaration
4. Name and address of the provider
5. Description of the product/service

The declaration must be kept for 5 years and made available to market surveillance authorities on request.

Required documentation:

• VPAT / Accessibility Conformance Report (ACR)
• Accessibility Statement published on your website
• Internal test records (automated + manual testing)
• Remediation log for known issues

5.2 Notified Body Assessment

For higher-risk services (financial, healthcare, critical infrastructure) or where self-declaration credibility is commercially important, you can engage an EU-notified conformance body. The harmonised standard EN 301 549 provides the test methodology.

Notified bodies for EAA accessibility testing are designated by national market surveillance authorities. Major providers include Sogeti (France/Germany), BOIA (Netherlands), and Funka (Sweden/Germany).

6. Accessibility Statement Requirements

Your public accessibility statement must contain (Article 13(2)):

ACCESSIBILITY STATEMENT

[Product/Service Name] complies with the requirements of 
Directive 2019/882/EU (European Accessibility Act) in 
accordance with EN 301 549:2021+A1:2023.

Conformance Level: WCAG 2.2 Level AA

Known Limitations:
- [Issue]: [Description and alternative access path]
- [Issue]: [Description and timeline for fix]

Assessment Approach: Self-evaluation / Third-party audit

Testing date: [Date]

Contact for accessibility issues:
Email: [accessibility@yourdomain.eu]
Response time: [e.g., 5 business days]

Enforcement body (Germany): 
Schlichtungsstelle nach dem Behindertengleichstellungsgesetz
Tel.: +49 30 18 527-2805

Member states must designate an enforcement body and a dispute resolution body. Users with disabilities can complain to the enforcement body if a service is not accessible.

7. Enforcement: Penalties by Member State

The EAA requires member states to set "effective, proportionate, and dissuasive" penalties. Here is the status across key markets:

8. Interaction With Other EU Regulations

EAA × GDPR (Regulation 2016/679)

Article 5(1)(a) GDPR — lawfulness, fairness, and transparency — requires that privacy notices be understandable. WCAG 2.2 accessible privacy notices satisfy both GDPR transparency and EAA accessibility requirements simultaneously.

Cookie banners must themselves be accessible: keyboard-navigable, screen-reader-compatible, with sufficient contrast. An inaccessible cookie consent interface violates both GDPR (invalid consent under Art.7) and EAA.

EAA × EU AI Act (Regulation 2024/1689)

Article 8(1) AI Act requires high-risk AI systems to meet transparency and information requirements including that information provided to users be accessible. This creates a constructive overlap:

• High-risk AI SaaS products must be EAA-accessible
• AI-generated UI components must not degrade accessibility
• Automated decision outputs must be comprehensible to users with cognitive disabilities

EAA × CRA (Regulation 2024/2847)

For SaaS products classified as "products with digital elements" under the CRA, accessibility falls within the CRA's broader product safety requirements. Article 13 CRA documentation requirements include information "necessary for the safe use of the product" — which could be read to encompass accessibility where it affects safety (e.g., medical device software).

EAA × Web Accessibility Directive (WAD, Directive 2016/2102)

The WAD covers only public sector websites and mobile apps. The EAA extends equivalent requirements to the private sector. If you provide services to both public authorities and consumers, you face WAD requirements for the public-sector deployment and EAA requirements for consumer access. Both reference EN 301 549.

9. Testing Strategy for SaaS Teams

Automated Testing (covers ~30-40% of WCAG issues)

# axe-core via CLI (free, reliable)
npx @axe-core/cli https://app.yoursaas.io --rules wcag2a,wcag2aa,wcag22aa

# Lighthouse accessibility audit
npx lighthouse https://app.yoursaas.io --only-categories=accessibility --output=json

# WAVE API (commercial, production monitoring)
curl "https://wave.webaim.org/api/request?key=YOUR_KEY&url=https://app.yoursaas.io&format=json"

Integrate accessibility tests in your CI pipeline:

# GitHub Actions example
- name: Accessibility test
  run: |
    npx @axe-core/cli $STAGING_URL \
      --rules wcag22aa \
      --exit-code 1 \
      --reporter json \
      > accessibility-report.json

Manual Testing (required for remaining ~60-70%)

1. Keyboard-only navigation: Tab through all UI without mouse. Can you reach and operate every control?
2. Screen reader testing: NVDA + Firefox (Windows), VoiceOver + Safari (Mac), TalkBack (Android)
3. Zoom to 400%: Does content reflow without horizontal scrolling (SC 1.4.10)?
4. Colour contrast: Use browser DevTools → Accessibility → Contrast ratio. Min 4.5:1 for normal text, 3:1 for large text (SC 1.4.3)
5. Focus indicator visibility: Ensure custom focus styles are visible (SC 2.4.7, 2.4.11)
6. Form error identification: Is every error clearly linked to its input field (SC 3.3.1, 3.3.2)?

EAA-Specific Test Items

10. Implementation Checklist

Use this before your next deployment:

Immediate (Legal Exposure Without These)

• Publish accessibility statement at /accessibility or /accessibility-statement
• Include EAA compliance in your Terms of Service
• Designate an internal accessibility contact (email required in statement)
• Run automated scan — axe, Lighthouse, or WAVE — and document results
• Fix WCAG 2.2 Level AA failures (not just warnings)

Short-Term (Within 30 Days)

• Manual keyboard navigation test on core user flows
• Screen reader test on login, onboarding, main dashboard
• Audit all drag-and-drop interactions for pointer alternatives (SC 2.5.7)
• Verify minimum target sizes for icon buttons (SC 2.5.8)
• Check that sticky headers don't obscure focused elements (SC 2.4.11)
• Review cookie consent banner for accessibility

Ongoing

• Integrate axe-core in CI/CD pipeline
• Include accessibility acceptance criteria in all new feature specs
• Update accessibility statement after each sprint with known issues
• Annual third-party audit for products in financial/healthcare sectors
• Document your VPAT (Voluntary Product Accessibility Template)

11. Hosting and Infrastructure Considerations

The EAA applies to services provided to consumers in the EU regardless of where the provider is headquartered. A SaaS company headquartered in the US serving EU consumers must comply.

However, EU-based infrastructure creates operational advantages for EAA compliance:

Data residency: Accessibility monitoring tools that collect user session data (screen reader usage patterns, keyboard navigation heatmaps) generate personal data. Processing this data on EU infrastructure avoids cross-border transfer issues under GDPR Chapter V.

Support response times: EAA enforcement bodies and dispute resolution bodies operate on EU business hours. Having EU-based customer support and technical teams makes the required 5-business-day accessibility feedback response realistic.

Notified body proximity: EU-based accessibility conformance assessment bodies have jurisdiction advantages for generating legally accepted conformance reports in target markets.

Summary

The European Accessibility Act has been enforceable since June 2025. For SaaS developers serving EU consumers:

1. Determine if you're in scope — most B2C SaaS services are; microenterprises (<10 employees, <€2M revenue) are exempt for services
2. Implement WCAG 2.2 Level AA — the harmonised standard EN 301 549 maps EAA to WCAG criteria
3. Pay special attention to WCAG 2.2 additions — SC 2.5.7 (dragging), SC 2.5.8 (target size), SC 2.4.11 (focus obscured), SC 3.3.8 (accessible auth)
4. Publish an accessibility statement — legally required, must list known issues and contact info
5. Document conformance — VPAT/ACR for self-declaration or engage an EU notified body
6. Integrate accessibility testing in CI — automated tools catch 30-40% of issues early

Penalties vary by member state but reach up to €900,000 in the Netherlands and 5% of annual turnover in Spain. The market surveillance enforcement regime is active — proactive compliance is significantly less expensive than reactive remediation after an enforcement action.