Are You Ready for the June European Accessibility Act Launch?

You have an accessibility process testing against WCAG, but there’s a little more you must do for the EAA

William Reuschel started his section by providing an understanding of how the EAA actually gets transposed into national laws in EU member states. The European Accessibility Act is what everyone is going to call this new European law. It’s actually a directive, and there are local laws that are actually implementing the EAA. For example, in Germany you might have the BFSG, and in France and Italy there are different decree numbers that specify exactly how that individual country has implemented the EAA.

There might be some differences in the specific requirements between each of the different countries, but the European Commission has recommended two technical standards. The first one is EN 301 549, which is the accessibility requirements for Information and Communication Technology (ICT) products and services. And then the other one is the design for all standards, EN 17161.

Reuschel covered how product owners — especially those already testing against WCAG — should think about adapting their current accessibility efforts to meet the EAA. WCAG compliance is great, but it’s not the whole story. WCAG is incorporated into EN 301 549, so most of your accessibility work will carry over. However, EN 301 549 contains WCAG requirements plus some more. There is also the optional process-oriented standard too, EN 17161. It focuses on organizational commitment, not product features. It encourages involving real users with disabilities in your accessibility efforts and recommends embedding accessibility into design and development processes.

The key takeaway? If you’ve done the work already, you’re not starting from zero, but product owners need to move from “doing accessibility” to operationalizing accessibility across teams.

How WCAG testing stacks up to EN 301 549

Chapter-by-chapter breakdown of EN 301 549

Chapters 1–4: General & Informative. These early chapters cover the scope of the standard, definitions and overarching functional performance criteria. They provide the “why” behind the requirements. Think of them as the standard’s mission statement — the product should work for people with various disabilities (low vision, no hearing, no manual dexterity, etc.).

Chapter 5: Generic Requirements. Mostly focuses on hardware or software with closed functionality — meaning no ability to modify or interact with assistive technology. It also includes items like biometric systems (e.g., fingerprint scanners), ensuring these can be used by people with disabilities.

Chapter 6: Two-Way Voice Communication. This applies to platforms that offer real-time speech interaction — like voice calls or chat via VoIP. The goal here is to ensure speech can be clearly transmitted and understood, especially for users relying on speech-based tech or relay services.

Chapter 7: Support for Captions and Audio Descriptions. This is about the media players, not the media itself. If your product hosts video or audio content, the player must support key accessibility features like captions and audio descriptions,  including the ability to turn them on/off easily.

Chapter 8: Hardware Requirements. For companies building physical devices, this chapter provides consistent, testable standards to ensure that buttons, screens, connectors, and interactions are accessible. It’s relevant for embedded systems, kiosks, ATMs, and similar products.

Chapter 9: Web Content. This is WCAG in disguise. It’s a direct implementation of WCAG 2.1, applied to websites. If you’re already testing your websites for WCAG compliance, this chapter should feel very familiar — and most of your current processes apply here.

Chapter 10: Non-Web Documents. Now, documents like PDFs, Word files, and email content are explicitly in scope. This codifies what’s been a strong recommendation for years: any document delivered to a user must meet accessibility standards, not just your website.

Chapter 11: Software (Desktop & Mobile Apps). Here, WCAG is re-applied to native apps and non-web software, including mobile apps and desktop tools. A few additional checkpoints exist to accommodate functionality that’s unique to apps (like gestures or platform-specific UI).

Chapter 12: Documentation and Support. This chapter says that any help materials, product guides, and support services (email, chat, contact centers) must be accessible. Plus, support staff must understand the product’s accessibility features and be able to help users with disabilities effectively.

Chapter 13: Emergency Services. If your product connects users to emergency services — like 911 equivalents — this chapter applies. It includes requirements around communication modes, fallback systems, and making sure those services are accessible in urgent, real-time scenarios.

Reuschel wrapped up by stating that if your team is already doing the right things with WCAG, you’re approximately at 90% of EN 301 549. Now is the time to expand your scope and plug the remaining gaps — especially in documentation, support and non-web content.