What is the European Accessibility Act (EAA): Checklist 2025

The European Accessibility Act is an EU directive that requires key digital products and services to be accessible to people with disabilities. Its legal basis is built around EN 301 549 and WCAG 2.1 Level AA standards.

As of June 2025, the European Accessibility Act (EAA) is in full effect, making accessibility mandatory for digital products and services.

This article explains the EAA accessibility compliance requirements, how to meet them, and what happens if you don’t.

What is the European Accessibility Act (EAA)?

The EAA is a directive passed by the European Union in 2019. Its main goal is to ensure people with disabilities have equal access to a wide range of digital and physical products and services. This includes digital platforms like e-commerce sites, banking services, transport booking apps, communication tools, and hardware like ATMs and e-readers.

The law aims to remove market fragmentation caused by inconsistent accessibility laws in EU countries. It sets a baseline standard that applies across the EU, helping businesses create accessible offerings at scale.

Note: The EAA is built on technical standards such as EN 301 549 and WCAG 2.1 and aligns with the principles of the United Nations Convention on the Rights of Persons with Disabilities.

Why was the EAA Accessibility Compliance Introduced?

Before the EAA, accessibility rules were inconsistent across the EU. Some countries had strict laws, while others had none. This created problems for people with disabilities and made it harder for businesses to operate across borders.

The EAA addresses this by:

• Establishing a unified set of accessibility obligations across all EU member states reduces legal fragmentation and makes compliance predictable for multinational businesses.
• Bringing consistency to product development so that accessibility can be integrated early in the design and engineering lifecycle, rather than retrofitted for each market.
• Requiring accessibility as a functional outcome, not just a technical specification. This means users must be able to complete tasks, consume content, and interact with services using assistive technologies, not just pass automated tests.
• Aligning the EU’s legal framework with the United Nations Convention on the Rights of Persons with Disabilities, treating digital accessibility as a human right.
• Creating legal clarity for businesses and public sector entities reduces the risk of litigation and consumer complaints.

When does the EAA Accessibility Compliance take effect?

The European Union officially adopted the European Accessibility Act in June 2019, marking the beginning of a multi-phase rollout process. Under the directive, each EU member state was given until June 28, 2022, to incorporate the EAA into national legislation. This step, known as transposition, ensures that the directive becomes legally enforceable at the country level.

Once the law is transposed, businesses operating in or targeting EU markets must achieve compliance by June 28, 2025. This three-year window was intended to give organizations sufficient time to audit their systems, update infrastructure, train teams, and adopt new testing practices.

Important: The European Accessibility Act is now in effect, and organizations that have not met the requirements are now at legal and reputational risk.

Who does the EAA apply to?

The EAA applies to both public and private organizations that offer products or services in the EU. This includes EU-based companies and non-EU businesses selling into the EU market.

Sectors and services covered by the EAA:

1. E-commerce websites and apps
2. Online banking and financial services
3. Telecom services and hardware
4. Transport services like booking platforms and check-in kiosks
5. E-books and e-readers
6. ATMs, ticketing machines, and self-service terminals

Note: Microenterprises that offer services but employ fewer than 10 people and have an annual turnover below EUR 2 million may be exempt. However, this exemption varies by country.

What Does EAA Accessibility Compliance Involve? (Checklist 2025)

EEA evaluates accessibility based on EN 301 549 and WCAG 2.1 Level AA standards. Here’s how to ensure compliance with EAA accessibility.

1. Make your digital content perceivable People with visual, auditory, or sensory impairments need to be able to access and interpret your content through multiple formats and assistive tools. The goal is to ensure everyone can see, hear, or perceive what’s on screen.

• Add descriptive alt text to all non-decorative images
• Avoid using images of text unless absolutely necessary
• Provide accurate subtitles, captions, and transcripts for all audio and video content
• Use a minimum color contrast ratio of 4.5:1 for standard text and 3:1 for large-scale text
• Ensure that all content remains usable and readable when zoomed in up to 200%
• Structure all content using proper heading levels (H1–H6) to provide a clear hierarchy
• Use meaningful link text (e.g., “Download Report” instead of “Click Here”)
• Include text alternatives for any CAPTCHA (e.g., audio or logical puzzle alternatives)

2. Make your interfaces operable Your interface must be usable by people with different physical abilities, including those using keyboards, switch devices, screen readers, or other assistive tech. Nothing should be mouse-only or rely solely on gestures.

• Ensure all functionality can be accessed using a keyboard (no mouse required)
• Make sure focus indicators are visible (e.g., outlines on focused buttons or links)
• Avoid flashing content that could trigger seizures (limit to 3 flashes per second or less)
• Provide enough time for users to complete tasks or read content
• Ensure all touch targets (like buttons) are large enough and spaced properly
• Maintain a consistent navigation layout and menu structure across screens/pages
• Ensure dropdowns, modals, and dynamic content updates are accessible and usable

3. Make your content understandable Even if your content is visible and operable, it won’t be usable unless people understand it. Use clear language and predictable interactions, especially for people with cognitive or learning disabilities.

• Write in plain, simple language and avoid unnecessary jargon or complex words
• Label form inputs clearly (e.g., “Email Address” rather than just “Email”)
• Display error messages in context with clear suggestions for correction
• Use consistent navigation, icons, buttons, and layouts throughout the experience
• Explain any abbreviations, acronyms, or technical terms the first time they appear
• Support multiple languages if applicable, and indicate language changes in code

4. Make your code and technology robust Your product should have clean, standard-compliant code that works across different browsers, platforms, and assistive technologies. This ensures long-term compatibility and reliable accessibility.

• Use semantic HTML elements (like <nav>, <header>, <main>, <button>, etc.)
• Avoid using<div> or <span> for interactive elements unless ARIA roles are added
• Only use ARIA labels when necessary, and use them correctly
• Ensure all UI elements have a name, role, and value programmatically defined
• Validate your HTML, CSS, and JavaScript regularly for accessibility errors
• Test your product with multiple assistive tools: NVDA, JAWS, VoiceOver, TalkBack
• Ensure that custom widgets (e.g., accordions, sliders) are fully accessible

5. Apply accessibility to physical products and customer services The EAA also applies to physical self-service devices (like ATMs and ticket machines) and how you deliver services. Everyone must be able to interact independently and get help from your systems.

• Ensure ATMs, kiosks, and e-readers have tactile buttons or audio output options
• Offer headphone jacks and audio guidance for private navigation on public devices
• Make screens anti-glare and text readable in varied lighting conditions
• Provide alternative input methods (e.g., physical buttons if the touchscreen is not usable)
• Offer instructions in multiple formats (audio, visual, tactile, where needed)
• Ensure websites and apps used in transport, banking, or e-commerce are fully accessible

6. Test, maintain, and document your accessibility efforts

Regular testing, feedback, and documentation are key to staying compliant.

• Conduct manual accessibility testing, including keyboard-only navigation and screen reader use
• Include users with disabilities in your usability testing process
• Track and resolve accessibility bugs as part of your QA or sprint process
• Maintain internal accessibility documentation and keep it updated
• Offer regular accessibility training for your developers, designers, and content creators
• Keep a changelog or audit trail of accessibility issues and fixes for compliance records

What Happens if You Don’t Comply with EAA?

Here’s a detailed look at what businesses can expect if they fail to meet the requirements:

1. Investigations and Inspections by National Authorities

Each EU member state is required to appoint one or more market surveillance authorities to oversee EAA enforcement. These authorities are empowered to:

Investigate products and services suspected of non-compliance.

Conduct inspections or audits, including requesting accessibility documentation or test results.

Follow up on consumer complaints and accessibility violation reports.

Note: A single user complaint about inaccessible navigation, forms, or checkout flows can trigger an inquiry.

2. Mandatory Remediation Orders

If your product or service is found to be non-compliant, the regulator can issue a formal notice requiring you to fix the issue by a set deadline. This could include:

• Making your website or app meet WCAG 2.1 AA standards.
• Fixing keyboard traps, unlabeled elements, or inaccessible components.
• Updating user documentation, customer support channels, or hardware instructions.

You’ll usually be allowed to correct the problem, but the timeline is strict. Failure to resolve the issue within the prescribed period will escalate the enforcement.

3. Public Disclosure of Violations

In many member states, repeated or severe violations may be made public. Some regulators maintain a register of companies that have failed to comply with accessibility laws. This affects brand reputation, can influence procurement decisions, and increases scrutiny from regulators and users alike.

For example:

• Denmark publishes non-compliance notices publicly for the public sector and private companies.
• France’s accessibility scorecard includes the names of organizations that do not publish or update required accessibility statements.

4. Product Withdrawal or Service Suspension

If a non-compliant product poses a critical barrier, especially in essential services like payments, public transportation, or banking, regulators can take stronger action:

• Suspend a product or feature from being sold or used in the EU market until compliance is achieved.
• Order a recall of a physical product if its interface or documentation is inaccessible.
• Restrict or block access to a digital service or portal that systematically excludes users with disabilities.

This typically happens after failed remediation efforts or in high-risk sectors where user safety or core rights are impacted.

5. Fines and Administrative Penalties

Under the EAA, all EU member states are required to impose effective, proportionate, and dissuasive penalties.

For example, here is what some countries charge:

• Germany: Under the Behindertengleichstellungsgesetz (BGG), fines can reach €100,000 per violation.
• France: Fines of up to €50,000 can be issued for missing or incomplete accessibility declarations, with additional penalties for unresolved technical barriers.
• Austria: Under the Barrierefreiheitsgesetz, fines can reach €35,000. Authorities focus on dispute resolution first, and users can get support from the consumer protection agency.
• Italy: Fines can reach €25,000, especially if users are blocked from completing critical actions like payments or form submissions.
• Spain: Penalties range from €30,001 to €90,000, depending on severity and whether the violation is classified as minor, serious, or very serious.

Common EAA Accessibility Compliance Challenges

Most accessibility issues stem from structural gaps in how teams work, prioritize, or rely on tools that don’t test real experiences.

1. Older Platforms That Weren’t Designed for Accessibility

Many platforms still run on legacy systems built before accessibility standards became a legal or product priority. These older systems often:

• Don’t support ARIA (Accessible Rich Internet Applications) roles, so screen readers can’t interpret the interface correctly.
• Lacks proper keyboard navigation support, making it hard or impossible for users who rely on keyboards to move through the site.
• Use rigid layouts that don’t adapt well to screen zoom or responsive scaling, which causes issues for users with low vision.

Updating these systems to meet modern accessibility standards usually requires significant refactoring, which teams may postpone due to cost or time constraints.

2. Third-Party Components That Introduce Accessibility Gaps

Many products rely on external tools embedded directly into the user interface. These tools might not meet accessibility standards, but teams often assume compliance is someone else’s responsibility.

This assumption causes real problems when users encounter the following:

• Chat widgets that cannot be accessed using a keyboard.
• Payment provider iframes that trap keyboard focus and prevent users from moving forward or exiting the form.
• Video players, booking engines, or consent banners that lack proper labeling, contrast, or focus behavior.

These elements are part of the overall user journey. If they are inaccessible, your product is not compliant, even if the rest of your platform meets the guidelines.

3. Lack of Coordination Between Design, Development, and QA

Accessibility problems often come from mismatched priorities across different teams. Each group may be working toward good outcomes individually, but without shared ownership of accessibility, the product ends up with serious gaps.

Here are common reasons:

• Designers may include modals, carousels, or other interactive elements without defining how keyboard users should navigate them.
• Developers may focus on how things look and function visually, but skip over semantic HTML or ARIA roles that assistive technologies depend on.
• QA may run visual and functional tests, but not test for screen reader output, keyboard flow, or contrast issues.

4. Inconsistent Component Behavior Across the UI

Teams often build or use UI components that behave differently in different application parts. This is especially common in large platforms with multiple teams contributing code. Without shared standards or enforcement, users experience inconsistent or broken interactions.

Some examples of how this affects accessibility:

• A dropdown menu on one page supports keyboard navigation and ARIA roles, but the same component elsewhere doesn’t respond to the arrow keys or return focus to the trigger after selection.
• One set of buttons has visible focus outlines and screen reader labels, while another set, built by a different team, does not.
• Components used across the product are styled differently, respond differently to screen readers, or behave unpredictably with keyboard input.

Tools like BrowserStack help teams catch these inconsistencies early by testing components in real user environments. You can validate keyboard behavior, focus management, and screen reader compatibility across browsers and devices.

Best Practices for Long-Term EAA Readiness

Meeting the European Accessibility Act (EAA) requirements by the 2025 deadline is necessary, but staying compliant over the long term requires structural and ongoing effort. Accessibility is not a one-time checklist item. It has to be built into how teams design, develop, test, release, and maintain digital products.

Below are key practices that help teams stay aligned with EAA requirements over time.

1. Define Clear Ownership Across the Product Lifecycle

Accessibility efforts often fail because they are split across teams, with no one accountable for the whole picture. Everyone touches the product, but no one tracks accessibility from beginning to end.

What to do:

• Assign a clear owner who is responsible for accessibility across teams. This could be a compliance lead, an accessibility program manager, or someone in product operations.
• Document the responsibilities for each role, including what designers, developers, QA testers, and content writers are expected to check.
• Integrate accessibility tasks into your product lifecycle stages instead of leaving them to the last sprint.

2. Build Accessibility into Your Component Library

Accessibility defects often come from reused components that were not built properly in the first place. If your design system or component library is not accessible, those problems will show up in every feature that uses them.

What to do:

• Maintain a shared component library that meets WCAG 2.1 AA and aligns with EAA requirements.
• Document expected behaviors, including keyboard navigation, ARIA roles, and screen reader output for each component.
• Require teams to use pre-approved components and prevent ad-hoc UI elements without review.

3. Train Teams on Real Scenarios, Not Just Guidelines

Teams do not need more high-level checklists. What works better is training that uses their actual product and shows how accessibility issues affect real users.

What to do:

• Provide training that is specific to each role. Developers must learn to write semantic HTML, QA should test keyboard flow and screen reader behavior, and designers must structure content and interactions for accessibility.
• Run group audit sessions using your own product. Let teams inspect live issues and practice identifying what needs to be fixed.
• Make assistive technology part of onboarding. Show teams how real users navigate with screen readers, voice commands, or zoom tools.

4. Monitor Embedded Third-Party Tools

External tools often introduce accessibility violations without warning. These include payment forms, chat widgets, consent managers, and booking modules. Even if your own code is compliant, these third-party elements can create serious problems for users.

What to do:

• Keep a record of all third-party scripts and modules in use and their accessibility status.
• Include accessibility language in your vendor contracts. Ensure suppliers are required to follow WCAG 2.1 AA and provide regular updates.
• Re-audit these tools on a schedule, especially after product updates from the vendor.

5. Use User Feedback to Identify Real Problems

Some accessibility issues never appear in audits or test scripts but are reported by users. Support teams often get early signals about these problems, but they do not always reach product or engineering teams.

What to do:

• Train customer support to tag and escalate accessibility-related feedback.
• Add accessibility-related questions to satisfaction surveys for critical user journeys.
• Set up a feedback loop so teams can review, prioritize, and respond to issues raised by users with disabilities.

6. Run Accessibility Tests on Real Devices and Browsers

Emulators and simulators are helpful during development, but they often miss critical issues that show up only in real-world environments. These tools cannot fully simulate how actual assistive technologies behave or how browser-device combinations affect accessibility.

For example, they may not catch issues like screen reader announcements that don’t trigger correctly, focus indicators that are hidden due to OS-level styling, or touch target sizing problems on mobile.

What to do:

• Test your product on real devices, including phones, tablets, and desktops across different operating systems.
• Use actual assistive technologies, such as VoiceOver on Safari, TalkBack on Android, or NVDA on Windows.
• Validate user flows in real browsers to catch rendering, focus, or interaction issues that don’t appear in emulated setups.

BrowserStack Accessibility Testing helps teams overcome these limitations by enabling testing on 3,500+ real devices and browsers. You can test actual user flows with real assistive technologies like VoiceOver on Safari, TalkBack on Android, or NVDA on Windows to uncover interaction, focus, and rendering issues early.

Conclusion

The European Accessibility Act is now in full effect, with the compliance deadline already passed on June 28, 2025. Any organization offering digital products or services in the EU must now be fully accessible. Non-compliance can lead to fines, service restrictions, and damage to brand reputation.

BrowserStack helps teams meet EAA obligations by enabling testing against WCAG 2.1 standards across real devices and browsers. It supports screen readers like VoiceOver and TalkBack, checks for keyboard navigation, color contrast, and semantic structure, and integrates directly into CI/CD pipelines. This ensures teams can catch and resolve issues in real user scenarios.