Disclaimer: As digital accessibility is our specific wheelhouse, we’re keeping this focused on digital products and services.

WCAG compliance is necessary—but it’s not enough.

Most teams know accessibility is important. The real challenge now is execution—how to meet growing regulatory demands without slowing down development or overloading operations. And as regulations like the European Accessibility Act (EAA) and Section 508 tighten, we can’t afford to manage accessibility the same way we always have.

With the EAA and related national legislation providing a new basis standing to bring legal proceedings related to inaccessible products and services, the June 28th 2025 enforcement deadline was swiftly followed by formal notices. Notably, in France, disability associations have already issued formal notices to some major retailers requiring them to make their online services accessible by September 1st or face legal proceedings.

With the EAA officially in full steam, teams across the EU (and global companies operating in Europe) are revisiting their accessibility strategies. When it comes to the digital space, many assume that meeting WCAG 2.1 AA—or even AAA—means they’re covered.

They’re not.

It’s easy to see where this confusion comes from though:

• WCAG is referenced in the EAA’s harmonized standards via EN 301 549.

• EN 301 549 is the current technical specification for digital accessibility.

Most accessibility blogs stop right there.

The EAA is a law, and the law goes far beyond just whether your digital product passes an automated WCAG-conformance testing. Products and services are presumed to conform with the accessibility requirements of the EAA, so long as they meet the requirements of the relevant harmonised standards (Article 15(1)). As of July 2025, the relevant harmonized standards published in the Official Journal of the European Union are¹:

• EN 301 549 Accessibility requirements for ICT products and services

• EN 17161:2019 Design for All - Accessibility following a Design for All approach in products, goods and services - Extending the range of users

The EAA is broader in scope, deeper in responsibility, and more aligned with how organizations govern privacy and security than how they typically manage accessibility today. This post breaks down the key differences and introduces a more complete way to think about accessibility compliance across your org.

Why WCAG isn’t (and wasn’t ever) enough for the software of tomorrow

WCAG guidelines focus heavily on web content accessibility—color contrast, headings, navigation order, focus states, etc. That’s necessary, but not sufficient.

The EAA introduces additional, legally binding requirements that go beyond the UI layer:

So yes—you can pass WCAG AA and still fail to comply with the EAA’s digital product obligations.

So what is EAA's scope for Digital Products?

Under the EAA, digital products and services—including software, websites, mobile apps, e-books, digital banking interfaces, ticketing systems, and operating systems—must meet functional accessibility requirements across the full service lifecycle.

That includes:

• Information delivery: Can a customer receive, understand, and act on digital information at every stage of use (marketing, purchase, support, cancellation)?
  

• Interoperability: Does your product function with assistive technologies, across platforms and device types?
  

• Usability across contexts: Is the digital product accessible whether it’s used on desktop, mobile, or embedded systems?
  

• Support, documentation, and post-sale experience: Can users access help and complete tasks like cancellation or refunds without barriers?

In short: It’s not just “can a screen reader access this screen?” It’s “can any user complete the full experience without needing adaptation or assistance?”

If your team already manages privacy and security through a combination of internal policies, automation, ownership, and documentation—you already know the structure that’s needed.

EAA Compliance requires organizational readiness

This is where EN 17161 becomes relevant.

While WCAG and EN 301 549 tell you what to make accessible, EN 17161 helps you structure how to make accessibility sustainable across teams. It’s less about individual design decisions and more about embedding accessibility into company operations.

Think of it like ISO 27001, but for accessibility governance.

EN 17161 emphasizes:

• Role-based ownership → Cross-functional planning and leadership accountability (Clause 6.1, 6.2)
  

• End-to-End Continuous Detection + Remediation → Integrating accessibility from the earliest product stages (Clause 6.3)
  

• Risk Mitigation and Traceability → Risk identification and mitigation throughout development (Clause 6.4–6.5)
  

• Vendor and third-party alignment (Clause 8.5)

• Centralized Reporting → Ongoing review and improvement (Clause 6.9–6.10)
  

When we say “EAA compliance requires a cross-functional approach” and “accessibility has to be operationalized, not audited” this is the structure we’re referring to.

What Stark Enables

Stark helps organizations go beyond WCAG—to build the infrastructure required for EAA, future legislation, and outright quality products as responsible and ethical software teams.

We’ve built an operating model designed to:

• Scale across departments

• Adapt to any jurisdiction

• Provide real-time visibility and control

• Align compliance with product velocity

It’s based on five dimensions of a company’s posture:

1. Technology – testing, monitoring, remediation throughout development

2. Culture – onboarding, rituals, incentives that drive inclusive behavior

3. Business Performance – measurable impact on cost, velocity, satisfaction

4. Internationalization – support for region-specific compliance

5. Policy – internal governance and external frameworks

With Stark, you can:

• Continuously Monitor accessibility posture in real time.

• Detect and Remediate within existing workflows as designers, engineers, legal, customer support, and more.

• Govern regulatory obligations into internal frameworks with clearly defined and assigned accountability across teams

To operationalize this model, Stark’s platform provides:

• Integrated Tooling: Real-time checks, alerts, remediation suggestions, and evidence captured across your workflow

• Reports: Insights and reporting on the progress, regress, or status of projects to ensure the removal of repetitious and retrofitted work, and maintenance of quality control.

• Centralized Compliance Hub: A shared view of progress, evidence for audit trails, owners, risks, and controls mapped per framework and region.

Traditional models are often used as linear checklists. But real progress isn’t linear—it’s multidimensional. Some teams may be advanced in culture but behind in tooling. Our model allows you to track exactly that.

Whether you’re preparing for compliance or building sustainable posture long-term, Stark gives you a system of record and system of action.

The EAA isn’t just “WCAG plus.” It’s a shift in how accessibility is treated across the lifecycle of a product or service.

This post is the first in our series on preparing for EAA—from interpreting its most misunderstood clauses and creating products with accessibility as a non-negotable quality requirement, to handling procurement and post-sale support. We’ll show you what modern accessibility compliance actually looks like, and how to build for it in the real world.

---

¹As the title suggests, EN 17210 Accessibility and usability of the built environment - Functional requirements has a focus outside of the digital space.

---

💬 Curious how your WCAG efforts map to EAA obligations, and how Stark can help? Book a quick chat and we’ll talk you through it. And for any thoughts and feedback at support@getstark.co, or join the conversations in our Stark Slack Community, on LinkedIn, and on Twitter.