European Accessibility Act (EAA): What Web Teams Need to Know Before June 2025

What Is the European Accessibility Act?

The European Accessibility Act (EAA), formally known as Directive (EU) 2019/882, is a European Union directive that establishes common accessibility requirements for certain products and services across all EU member states. It was adopted on April 17, 2019, and member states were required to transpose it into national law by June 28, 2022. The enforcement date — after which covered products and services must comply — was June 28, 2025.

The EAA is a directive, not a regulation. This means it sets minimum requirements that each EU member state must implement through its own national legislation. The specifics of enforcement, penalties, and some exemptions vary by country, but the core accessibility requirements are consistent across the EU.

The directive's purpose is to harmonize accessibility requirements across the EU single market. Before the EAA, accessibility laws varied significantly between member states, creating compliance complexity for businesses operating across borders and inconsistent protection for people with disabilities.

Key dates:

• April 17, 2019: Directive adopted by the European Parliament and the Council
• June 28, 2022: Deadline for member states to transpose the directive into national law
• June 28, 2025: Enforcement date — covered products and services must comply
• June 28, 2030: End of transitional period for service contracts entered into before June 28, 2025

Who Does the EAA Apply To?

The EAA applies to economic operators — manufacturers, importers, distributors, and service providers — that place covered products on the EU market or provide covered services to EU consumers. This includes non-EU companies that sell to EU customers.

Covered services (most relevant to web teams):

• E-commerce services: Any website or mobile application that sells products or services to EU consumers
• Banking and financial services: Online banking, payment services, investment platforms
• Telecommunications services: VoIP, messaging, telephone services
• Transport services: Websites, mobile apps, ticketing machines, and check-in services for air, bus, rail, and waterborne passenger transport
• E-books and dedicated reading software
• Audio-visual media services: Streaming platforms, video-on-demand

Covered products:

• Computers and operating systems
• Smartphones and tablets
• Self-service terminals (ATMs, ticketing machines, check-in kiosks)
• E-readers
• Consumer banking equipment

Micro-enterprise exemption: The EAA exempts micro-enterprises (fewer than 10 employees and annual turnover or balance sheet not exceeding EUR 2 million) that provide services. However, micro-enterprises that manufacture, import, or distribute covered products are not exempt. This exemption is narrower than many assume — a 5-person e-commerce shop with EUR 3 million in revenue is not exempt.

Disproportionate burden defense: The EAA includes a disproportionate burden provision, but it is not a blanket exemption. Businesses can claim that specific accessibility requirements would impose a disproportionate burden based on net costs relative to revenue, but they must document this assessment and still meet as many requirements as possible. National enforcement authorities can challenge disproportionate burden claims.

If you sell to EU customers through a website or app, the EAA likely applies to you, regardless of where your company is headquartered. A US-based SaaS company with EU customers needs to comply.

How the EAA Differs from WCAG

The EAA and WCAG are different things that work together. Understanding the distinction is essential for planning compliance.

WCAG is a technical standard — it tells you how to make web content accessible. It provides specific, testable success criteria (e.g., "text must have a 4.5:1 contrast ratio").

The EAA is a legal directive — it tells you that you must make your services accessible and establishes enforcement mechanisms. It does not specify pixel-level technical requirements itself.

The bridge between them is EN 301 549, the European harmonised standard for ICT accessibility. EN 301 549 incorporates WCAG 2.1 Level AA for web content (Section 9), mobile applications (Section 11), and software (Section 11), and adds additional requirements for things WCAG does not cover:

• Support for assistive technologies
• Documentation and support service accessibility
• Biometric identification alternatives
• Two-way voice communication (real-time text)
• Emergency service access requirements

Practical implications:

• Meeting WCAG 2.1 Level AA gets you most of the way to EAA compliance for web content, but it is not the complete picture
• EN 301 549 is being updated to reference WCAG 2.2 — teams should target WCAG 2.2 Level AA to future-proof their compliance
• The EAA has additional requirements beyond web content: your customer support must be accessible, your product documentation must be accessible, and your accessibility statement must be published
• Unlike WCAG (which has no built-in enforcement), the EAA has teeth — national authorities can order remediation, impose fines, and in extreme cases prohibit products from the EU market

Enforcement and Penalties

Each EU member state designates national market surveillance authorities to enforce the EAA. Enforcement mechanisms and penalties vary by country but must be "effective, proportionate, and dissuasive" per Article 30 of the directive.

Enforcement mechanisms include:

• Complaints: Individuals and representative organizations can file complaints with national authorities
• Market surveillance: Authorities can proactively monitor compliance, including testing websites and apps
• Corrective orders: Authorities can require businesses to bring non-compliant services into compliance within a specified timeframe
• Product withdrawal: For covered products, authorities can order removal from the EU market
• Fines: Financial penalties for non-compliance, set by each member state

Examples of national implementation:

• Germany (BFSG — Barrierefreiheitsstärkungsgesetz): The Federal Network Agency (Bundesnetzagentur) is designated as the market surveillance authority for telecommunications services; other authorities handle other sectors. Fines can reach up to EUR 100,000 per violation.
• France: Fines of up to EUR 50,000 per service or product for non-compliance, with potential doubling for repeat offenses.
• Netherlands: The Consumer and Market Authority (ACM) handles enforcement with powers to impose administrative fines.

What enforcement looks like in practice:

Enforcement is expected to follow a graduated approach:

1. A complaint is filed or an authority initiates an investigation
2. The business is notified and given an opportunity to remediate
3. If remediation is insufficient or not timely, formal orders and fines follow
4. Persistent non-compliance escalates to higher penalties and potential market prohibition

The early period after June 2025 is likely to see authorities focusing on education and voluntary compliance for minor issues, but reserving enforcement action for egregious cases and complaints-driven investigations. However, this "grace period" is not guaranteed and varies by country. Do not assume you have extra time.

Private litigation: Beyond regulatory enforcement, the EAA requires member states to ensure individuals can take legal action against non-compliant businesses. This opens the door to private lawsuits, similar to the wave of ADA web accessibility lawsuits in the United States.

The Accessibility Statement Requirement

The EAA requires that service providers publish information about how their service meets accessibility requirements. While the directive does not mandate a specific format for commercial entities (unlike the Web Accessibility Directive for public sector bodies, which specifies a model statement), publishing a clear accessibility statement is both a legal expectation and a practical necessity.

What your accessibility statement should include:

• Scope: Which website(s), applications, or services the statement covers
• Standard applied: Which accessibility standard you followed (e.g., WCAG 2.2 Level AA, EN 301 549)
• Conformance status: Whether the service fully conforms, partially conforms, or does not conform
• Known limitations: Specific accessibility barriers you are aware of, with explanations and planned remediation dates
• Feedback mechanism: How users can report accessibility issues and request accessible alternatives — include contact information (email, phone, or form)
• Enforcement procedure: Information about the relevant national enforcement body and how users can file a complaint
• Date: When the statement was last reviewed or updated

Where to publish it:

• Link from your website footer (accessible from every page)
• Use a clear label: "Accessibility" or "Accessibility Statement"
• The page itself must be accessible (it would be ironic if it were not)

Example opening:

[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. This statement was last updated on [date].

Keep it honest: An accessibility statement that claims full WCAG 2.2 conformance when the site has obvious accessibility issues is worse than no statement at all — it demonstrates awareness of the requirements combined with failure to meet them, which strengthens the case in any enforcement action. Be candid about known issues and your remediation plan.

Practical Steps for Compliance

Here is a concrete action plan for web teams preparing for or maintaining EAA compliance:

Phase 1: Assess (2-4 weeks)

1. Determine if the EAA applies to you: Review the covered services and products list. If you sell to EU consumers through a website or app, assume it applies.
2. Conduct an accessibility audit: Run automated scans (axe, WAVE, Lighthouse) across your key pages and flows. Complement with a manual expert review against WCAG 2.2 Level AA. If you lack in-house expertise, hire an accessibility consultancy.
3. Document your baseline: Record the number and severity of issues found, categorized by WCAG criterion. This becomes your remediation roadmap.
4. Review EN 301 549 requirements beyond WCAG: Check non-web requirements — is your support documentation accessible? Is your customer support reachable through accessible channels?

Phase 2: Remediate (4-12 weeks depending on scope)

1. Fix systemic issues first: Address problems at the component and template level — design system updates, global navigation, common form patterns. One fix that propagates across 100 pages is more efficient than 100 page-level fixes.
2. Prioritize by impact: Focus on issues that block access completely before addressing cosmetic or minor compliance gaps.
3. Test as you fix: Verify each fix with automated tools and manual testing (keyboard navigation, screen reader). Accessibility regressions are common if you fix without testing.
4. Address non-web requirements: Ensure support documentation (PDFs, help articles) is accessible. Ensure customer support channels are accessible (do not rely solely on a phone tree with no text alternative).

Phase 3: Sustain (Ongoing)

1. Integrate accessibility into your development process: Automated accessibility checks in CI/CD, accessibility criteria in code review checklists, accessibility training for new team members.
2. Publish your accessibility statement: Linked from the footer, honest about current status, with a clear feedback mechanism.
3. Monitor for regressions: Run automated scans regularly (weekly or per-deployment). Address new issues before they accumulate.
4. Respond to user feedback: When users report accessibility issues through your feedback mechanism, triage and resolve them promptly. A responsive feedback loop demonstrates good faith to enforcement authorities.
5. Stay informed: EN 301 549 is periodically updated. WCAG evolves. National implementations may add country-specific requirements. Designate someone on your team to monitor accessibility regulatory developments.

The EAA in Context: Other Accessibility Laws

The EAA does not exist in isolation. Understanding how it relates to other accessibility laws helps teams build a compliance strategy that covers multiple jurisdictions.

EU Web Accessibility Directive (WAD) — Directive 2016/2102:

The WAD applies to public sector bodies (government websites and apps). It has been in force since 2018-2020. The EAA extends similar requirements to the private sector. If you build websites for both public and private sector clients, you are now subject to accessibility requirements in both sectors.

Americans with Disabilities Act (ADA) — United States:

The ADA does not mention websites explicitly, but courts have increasingly interpreted it to apply to web services. In April 2024, the DOJ published a final rule (Title II) adopting WCAG 2.1 Level AA for state and local government websites. There is no equivalent Title III rule for private sector websites yet, but the litigation trend is clear. If you comply with the EAA (WCAG 2.1/2.2 Level AA + EN 301 549), you are well-positioned for ADA compliance as well.

Accessibility for Ontarians with Disabilities Act (AODA) — Canada/Ontario:

AODA requires WCAG 2.0 Level AA for large private sector organizations in Ontario. Broader Canadian federal legislation (Accessible Canada Act) is evolving. EAA compliance exceeds AODA requirements.

UK Equality Act 2010 and Public Sector Bodies Accessibility Regulations 2018:

Post-Brexit, the UK has its own accessibility framework. The public sector regulations mirror the EU WAD. The Equality Act applies to private sector service providers. Compliance with WCAG 2.2 Level AA satisfies UK requirements.

The practical takeaway: If you target WCAG 2.2 Level AA compliance and publish an accessibility statement with a feedback mechanism, you satisfy the core technical requirements of accessibility laws in the EU (EAA), the US (ADA case law), the UK, Canada, and most other jurisdictions. The specifics of reporting, statements, and exemptions vary, but the technical baseline is consistent.

Preparing Your Team

EAA compliance is not a one-time project — it is an ongoing operational requirement. Preparing your team means building sustainable practices, not just fixing a list of issues before a deadline.

Training:

• Ensure all developers understand semantic HTML, ARIA basics, and keyboard accessibility. These three areas account for the majority of accessibility defects.
• Train designers on accessible design patterns: color contrast, focus states, target sizes, responsive typography, and interaction patterns that work without a mouse.
• Train QA testers on accessibility testing fundamentals: keyboard-only navigation, basic screen reader usage, automated scanning tool interpretation.
• Train content authors on writing accessible content: heading structure, descriptive link text, image alt text, plain language.

Tooling:

• Integrate axe-core or pa11y-ci into your CI/CD pipeline to catch accessibility regressions automatically
• Add the axe DevTools browser extension to every developer's and QA tester's browser
• Configure your design tool (Figma, Sketch) with accessibility plugins for contrast checking and annotation
• Use a visual feedback tool that captures accessibility-relevant metadata (DOM state, ARIA attributes) alongside screenshots

Process:

• Add accessibility acceptance criteria to user stories: "All new form fields must have associated labels. New interactive components must be keyboard-operable."
• Include accessibility review in your code review checklist
• Schedule quarterly accessibility audits (even lightweight automated scans plus a manual spot-check) to catch drift
• Maintain your accessibility statement — update it when you fix issues or when new issues are discovered

Budget:

• Initial audit and remediation: Budget based on site complexity. A mid-size e-commerce site might require 40-80 hours of audit and 80-200 hours of remediation work.
• Ongoing: Allocate 5-10% of development time to accessibility maintenance. This is not additional overhead — it is part of building a quality product.
• Training: Plan for annual refresher training as team members rotate and standards evolve.

Frequently Asked Questions

Resources and Further Reading

• Directive (EU) 2019/882 — Full Text The official text of the European Accessibility Act from EUR-Lex
• EN 301 549 — ICT Accessibility Requirements The European harmonised standard for ICT accessibility, which the EAA references
• European Commission — European Accessibility Act Overview The European Commission's summary page on the EAA with FAQs and implementation guidance
• W3C WAI — Laws and Policies W3C's comprehensive list of accessibility laws and policies worldwide
• European Disability Forum Civil society perspective on the EAA, including implementation monitoring and advocacy

Related Guides