European accessibility act: What app builders need to know by 2025

In late 2024, a mid-size UK e-commerce company was expanding into Germany. Their legal team flagged the European Accessibility Act as a requirement for their German launch. The product team pushed back - they'd built to WCAG 2.1 AA, so they assumed they were covered.

They weren't.

Their iOS app failed EN 301 549 tests because native app touch targets were too small and they hadn't implemented VoiceOver support for custom product filters. Their checkout flow had a keyboard trap in the payment step that worked fine on web but broke completely on mobile. And their PDF receipts weren't tagged for screen readers.

They delayed the German launch by six weeks to fix the issues. Six weeks of lost revenue from a market they'd already paid to enter - all because they'd conflated "WCAG compliant" with "EAA compliant." They're not the same thing.

The European Accessibility Act (EAA) is not just another name for WCAG compliance. It's a directive with specific product categories, additional technical requirements beyond WCAG, national penalty frameworks, and an enforcement apparatus that doesn't rely on private lawsuits. If you're selling into EU markets, here's what you actually need to know.

What the EAA Is

The European Accessibility Act is EU Directive 2019/882. A directive isn't directly applicable EU law - it instructs each member state to pass equivalent national legislation. Member states had until June 28, 2022 to transpose the directive into national law. Products and services had until June 28, 2025 to comply with those national laws.

That means enforcement is now active in all EU member states.

The EAA was designed to solve a fragmentation problem. Before 2019, each EU country had different accessibility standards and enforcement mechanisms. A product that was accessible under German law might not meet French requirements. The EAA creates a single baseline across all 27 member states - though each state still sets its own penalty structure.

The goal was two-part: remove barriers for people with disabilities (roughly 87 million people in the EU have a disability, per the European Commission) and reduce compliance costs for businesses by giving them one standard instead of 27.

The timing matters. WebAIM's 2026 accessibility audit of the top 1 million web pages found that 95.9% of home pages had detectable WCAG 2.1 failures. The EAA didn't create an accessibility crisis - it created legal consequences for one that already existed.

Who must comply

Any business selling covered products or services to EU customers.

This includes companies based outside the EU. The EAA follows the same territorial logic as GDPR: if you serve EU customers, EU law applies. A US-based e-commerce store selling to German customers must comply. A Canadian banking app used by French customers must comply. An Indian SaaS company selling to Spanish businesses must comply.

The three-part test for coverage:

1. Does your product or service fall within the EAA's defined categories?
2. Do you sell it to customers in EU member states?
3. Are you above the microenterprise threshold?

If the answer to all three is yes, the EAA applies to you.

A Storyblok survey of 200 European professionals in digital roles found that only 25% of European businesses considered themselves fully prepared for EAA compliance. Nearly 29% lacked confidence in their preparation level, and 9.5% had no plans to make any changes at all.

The microenterprise exemption. Businesses that provide services (not physical products) and have fewer than 10 employees AND annual turnover or balance sheet under 2 million EUR are exempt for services. Both conditions must be true - not just one. A 8-person software company with 3 million EUR in revenue doesn't qualify. A 15-person company with 1.5 million EUR in revenue doesn't qualify. The exemption is genuinely narrow.

What the EAA covers

The directive defines its scope through a specific list. Understanding whether your product is in scope starts here.

Products in scope

Services in scope

If your product is a SaaS platform that powers any of these categories - you built the e-commerce backend, the banking app, the transport ticketing system - you're likely covered through your customers' compliance obligations even if you don't sell directly to consumers.

The technical standard: EN 301 549

The EAA doesn't specify technical requirements directly. It points to EN 301 549, the European standard for ICT (Information and Communication Technology) accessibility.

EN 301 549 is a larger document than WCAG. It covers:

• Web content (references WCAG 2.1 AA in full)
• Non-web software (native desktop and mobile apps)
• Non-web documents (PDFs, Office documents)
• Hardware

For web applications and websites, WCAG 2.1 AA is your primary technical benchmark. All 50 WCAG 2.1 AA success criteria apply.

But EN 301 549 adds requirements that WCAG doesn't address, particularly for native mobile apps:

Mobile-specific requirements:

• Touch targets must be at least 9mm x 9mm (about 44px x 44px at standard screen density)
• The app must work with the device's built-in accessibility features (VoiceOver on iOS, TalkBack on Android)
• Motion-based interactions must have an alternative that doesn't require device movement
• The app must not require simultaneous multi-point gestures for any core function (unless there's an alternative)

Document accessibility:

• PDFs and other documents provided by your service must be tagged for screen readers
• Document structure (headings, lists, tables) must be programmatically defined
• Form fields in documents must be labeled

Hardware (if applicable):

• Physical controls must be operable without fine motor control
• Visual and audible output must be supplemented for users who can't perceive one or the other
• Reach and size requirements for ATMs, kiosks, and terminals

EAA vs. ADA: The key differences

Many teams familiar with ADA compliance assume the EAA is similar. There are meaningful differences.

The enforcement difference is significant. ADA litigation is driven by private plaintiffs - often the same law firms filing hundreds of cases per year. EAA enforcement is driven by government bodies. That changes the risk profile. With ADA, the risk is a demand letter from a plaintiff firm. With EAA, the risk is a market surveillance authority investigation, which can result in product withdrawal orders and administrative fines - regardless of whether any individual user complained.

EAA vs. WCAG: They're not the same

WCAG is a set of technical guidelines published by the W3C. It has no legal force on its own. The EAA is law. WCAG 2.1 AA compliance is a necessary condition for EAA compliance for web content - but it's not sufficient.

Here's where WCAG-compliant products still fail EAA requirements:

Native apps. WCAG is written for web content. A WCAG-compliant web app doesn't automatically mean your iOS or Android app meets EN 301 549. Mobile apps need additional testing: VoiceOver and TalkBack compatibility, touch target sizes, motion alternatives, and gesture alternatives.

Documents. WCAG doesn't cover PDFs, invoices, receipts, or downloadable documents. EN 301 549 does. If your service provides any document output, it needs to be accessible.

The accessibility statement. The EAA requires a published accessibility statement that describes which parts of the product are accessible, which aren't, and what the user can do if they encounter a barrier. WCAG doesn't require this.

Functional performance statements. EN 301 549 requires that products meet functional performance criteria - nine statements about what users with different disability types should be able to do. These aren't tied to specific WCAG criteria; they're outcome statements that apply even when no specific technical criterion exists.

Penalties by member state

The EAA sets minimum standards for penalties but lets each member state determine the specific amounts. Here's what has been established in key markets:

These are per-violation figures. A non-compliant e-commerce platform that fails on multiple criteria could face multiple violations simultaneously.

Architecture implications

"Most teams we talk to conflate 'WCAG compliant' with 'accessible.' WCAG is a technical checklist for web content. EN 301 549 asks whether a person with a visual impairment can complete a checkout on your iOS app using VoiceOver - that's a different test with different results. We always run both, and we almost always find gaps in the native app layer even when the web product passes." - 1Raft Engineering Team

Accessibility at EAA scale isn't a single development sprint. It's a set of architectural decisions that need to be made early.

Component library accessibility

Every reusable UI component needs to meet accessibility requirements at the component level - not as a patch applied at the page level. If your button component doesn't handle keyboard events correctly, you have accessibility failures everywhere a button appears.

What this means in practice:

• Build accessibility into your design system's component specs
• Define ARIA roles, keyboard interaction patterns, and focus management for every custom component
• Test components in isolation against EN 301 549 criteria before composing them into pages

The cost of fixing an inaccessible component library is proportional to how many times that component is used. Fix it in the component, not in every instance.

Native app strategy

If your service has both a web interface and native mobile apps, both need to be accessible. They're not the same problem.

Your web interface's accessibility comes from semantic HTML, ARIA attributes, and keyboard navigation. Your native app's accessibility comes from using platform accessibility APIs correctly - UIAccessibility on iOS, AccessibilityNodeInfo on Android.

Common native app failures:

• Custom UI components that don't announce their role to the platform accessibility API
• Images and icons without content descriptions
• Focus order that doesn't follow the screen's logical reading sequence
• Gestures required for core functions without alternatives

Test with VoiceOver on iOS and TalkBack on Android as part of your QA process. Automated accessibility scanners don't catch most native app failures.

Document accessibility

If your service outputs any documents - invoices, receipts, reports, statements, tickets - those documents need to be accessible.

For PDFs:

• Generate tagged PDFs, not untagged (print-to-PDF is almost always untagged)
• Tag headings, paragraphs, lists, and tables with their semantic structure
• Add alt text to images in PDFs
• Ensure form fields are labeled
• Set the document language

Most PDF generation libraries support tagged PDF output. The question is whether your pipeline uses that capability.

Accessibility statement

The EAA requires a published accessibility statement. It's not optional. The statement must include:

• A description of what parts of the service are accessible
• A description of known barriers
• What users can do when they encounter a barrier (contact information for feedback)
• A link to the enforcement authority if the user's concerns are not addressed

Publish this as a dedicated page - not buried in your terms of service. Link to it from your footer.

Questions to ask your development partner

1. What's your approach to accessibility in your component library? The answer should describe accessibility as a component-level requirement, not a page-level fix. Ask to see how they handle custom dropdowns, modal dialogs, and form validation in terms of ARIA and keyboard behavior.

2. How do you test native app accessibility? Look for explicit mentions of testing with VoiceOver and TalkBack. If testing is limited to web, they're not prepared for EN 301 549's native app requirements.

3. Have you generated tagged PDFs in a production environment? This is a specific, non-obvious capability. If your service will output any documents, confirm your partner has done this before.

4. Can you walk me through how you handle touch target sizing and gesture alternatives in mobile apps? These are EN 301 549-specific requirements. A partner who knows the standard will answer specifically. A partner who doesn't will give you a vague answer about "mobile best practices."

5. What does your accessibility testing pipeline include? Look for automated testing (axe-core or equivalent) plus manual screen reader testing. Manual testing should cover keyboard-only navigation, VoiceOver, and TalkBack at minimum.

6. Have you produced an accessibility conformance report (VPAT/ACR) for a previous project? An ACR documents where a product meets and doesn't meet each EN 301 549 criterion. Enterprise clients and market surveillance authorities may request one. A partner who's produced one before understands the documentation requirements.

7. How do you handle accessibility during ongoing development? Accessibility often degrades between initial audits as features are added. Ask how they prevent regression - ideally through automated testing in CI/CD plus periodic manual audits.

EAA compliance checklist

Scope assessment:

• Product or service category confirmed to be in EAA scope
• EU customers confirmed (if yes to above, EAA applies)
• Microenterprise exemption status confirmed (if applicable)
• All product/service components inventoried (web, native apps, documents, hardware)

Web and web applications (WCAG 2.1 AA):

• All images have meaningful alt text or empty alt for decorative images
• All video has synchronized captions
• Color contrast meets 4.5:1 for normal text, 3:1 for large text and UI components
• All functionality is operable via keyboard alone
• Visible focus indicators on all interactive elements
• Form fields have programmatic labels (not just placeholder text)
• Error messages identify the problem and suggest a correction
• Skip navigation links present
• Page titles are descriptive and unique per page
• Language of page is declared in HTML
• Custom components have correct ARIA roles, states, and properties
• Dynamic content changes are announced to assistive technologies
• HTML validates (no duplicate IDs, proper nesting)

Native mobile apps (EN 301 549 additions):

• Touch targets are at least 9mm x 9mm (approximately 44x44px)
• App works with VoiceOver (iOS) and TalkBack (Android)
• All custom UI components announce role and state to platform accessibility APIs
• Images and icons have content descriptions
• Motion-based interactions have non-motion alternatives
• No core function requires simultaneous multi-point gestures without an alternative

Documents:

• PDFs are tagged (headings, paragraphs, lists, tables, images with alt text)
• PDF document language is set
• PDF form fields are labeled
• Non-PDF documents (DOCX, XLSX) have accessible structure when provided to users

Legal and procedural:

• Accessibility statement published (describes accessibility, known barriers, contact for issues)
• Accessibility statement linked from footer of all web pages
• Feedback mechanism for users to report accessibility barriers
• Compliance documentation maintained (audit reports, test results, conformance records)
• Accessibility conformance report (VPAT/ACR) available for enterprise customers or regulators

Testing:

• Automated accessibility scanning in CI/CD pipeline
• Manual keyboard navigation testing before each major release
• Screen reader testing with VoiceOver (Mac/iOS) and TalkBack (Android)
• Independent accessibility audit completed (or scheduled)
• Accessibility regression testing protocol in place for ongoing development

The deadline has passed. Member state enforcement authorities are active. If your product sells into EU markets and you haven't started an EAA compliance assessment, now is the time. An accessibility audit on an existing product typically costs $5,000-$20,000 depending on complexity. That's a fraction of the fines, product withdrawal orders, and remediation costs that come from enforcement action.

Build accessible, ship to Europe, stay there.