EU Accessibility Act 2025: A Developer's Practical Checklist

The European Accessibility Act (EAA, Directive 2019/882) became enforceable across all EU member states on 28 June 2025. Unlike WCAG, which is a technical standard, the EAA is a law. Non-compliant businesses selling products or services in the EU market face fines that range from €5,000 to over €500,000 depending on the member state and the severity of the violation. Some member states also permit market access restrictions — meaning authorities can block your product from being sold.

This article covers who is in scope, how enforcement works country by country, and a concrete 15-step developer checklist you can start working through today.

Who Is In Scope

The EAA covers businesses that sell products or services in the EU, with a focus on:

E-commerce: Any online shop selling to EU consumers, regardless of where the company is based
Banking and financial services: Online banking, mobile banking apps, payment terminals
E-books and dedicated reading software
Transport services: Ticket booking, real-time journey information, check-in systems
Telecommunications: Consumer communications services and related equipment
Audio-visual media services
Operating systems (for the hardware provisions)

There is a microenterprise exemption: companies with fewer than 10 employees AND annual turnover under €2 million are exempt from the service provisions (though not necessarily the product provisions). If you are a startup that sells into the EU, verify whether you qualify — but keep in mind that the exemption is narrower than it sounds and does not cover all situations.

Country-by-Country Enforcement

Each member state designates its own enforcement body and sets its own penalty structure. The EAA sets a floor, not a ceiling:

Germany: The Federal Network Agency (Bundesnetzagentur) and sector-specific regulators handle complaints. Germany has also implemented the Barrierefreiheitsstärkungsgesetz (BFSG), its national EAA transposition, with penalties up to €100,000 per violation.
France: RGAA (Référentiel Général d'Amélioration de l'Accessibilité) has been the national standard for public bodies since 2012; the DINUM now oversees EAA enforcement for private entities. Fines can reach €25,000 per violation with repeat-offender multipliers.
Spain: The RDA (Real Decreto de Accesibilidad) framework governs compliance. The ONCE (National Organization of the Spanish Blind) has historically been active in monitoring digital accessibility, and the government has indicated proactive enforcement posture.
Netherlands, Belgium, Sweden: These markets have historically strong accessibility advocacy communities and are expected to be early enforcement hotspots.

The Technical Standard: WCAG 2.1 AA + EN 301 549

The EAA references EN 301 549 as the harmonized European standard. EN 301 549 v3.2.1 incorporates WCAG 2.1 AA in full, plus additional requirements for non-web software, documents, and closed-functionality products. For most web developers, WCAG 2.1 AA conformance is the core target. Check the WooCommerce EAA guide or the Webflow EAA guide if you work on those platforms.

Developer Checklist: 15 Steps to EAA Compliance

Work through these in order. The first five items catch the most violations and are the fastest to fix.

1. Add lang attribute to <html>

<html lang="en"> <!-- or "de", "fr", "es", etc. -->
<!-- For multilingual pages, add lang to inline spans -->
<p>See also: <span lang="de">Datenschutz</span></p>

2. Every image needs meaningful alt text (or empty alt if decorative)

<!-- Informative image -->
<img src="product.jpg" alt="Blue canvas backpack with laptop compartment, 30L capacity" />

<!-- Decorative image -->
<img src="wave-divider.svg" alt="" role="presentation" />

3. All form inputs must have programmatically associated labels

<!-- Explicit label (preferred) -->
<label for="email">Email address</label>
<input type="email" id="email" name="email" autocomplete="email" required />

<!-- Error message announcement -->
<input
  type="email"
  id="email"
  aria-describedby="email-error"
  aria-invalid="true"
/>
<span id="email-error" role="alert">
  Please enter a valid email address.
</span>

4. Check color contrast — normal text 4.5:1, large text 3:1

Use the Certvo contrast checker or browser DevTools. EN 301 549 follows WCAG 1.4.3 exactly.

5. Ensure full keyboard operability

Tab through every interactive element. Nothing should trap focus. Modals must be dismissible with Escape. Custom widgets need complete keyboard event handling.

6. Provide captions for all pre-recorded video

This is WCAG 1.2.2 (Level A) and mandatory under the EAA. Auto-generated captions from YouTube or Vimeo need human review — accuracy matters for legal compliance.

7. Use semantic HTML elements

Replace <div class="button"> with <button>. Replace <div class="nav"> with <nav>. Semantic elements give assistive technologies the structural information they need without additional ARIA.

8. Make sure heading hierarchy is logical

One <h1> per page. Do not skip levels (h1 → h3, skipping h2). Headings should describe the section they introduce, not just be styled text.

9. All interactive elements need visible focus indicators

/* WCAG 2.2 adds Focus Appearance (2.4.11) —
   focus indicator must have 3:1 contrast against adjacent colors
   and an area of at least the perimeter of the component */
:focus-visible {
  outline: 3px solid #4f46e5;
  outline-offset: 2px;
}

10. Ensure touch targets are at least 24x24 CSS pixels (WCAG 2.2)

Mobile users need adequate touch target sizes. WCAG 2.2 Success Criterion 2.5.8 sets a minimum of 24x24 CSS pixels. The EAA's EN 301 549 v3.2.1 incorporates this.

11. Make sure error messages are specific and suggest corrections

WCAG 3.3.1 and 3.3.3: “Invalid input” is not sufficient. Say “Email must include an @ symbol.” Error messages must be programmatically associated with the field that triggered them (use aria-describedby).

12. Skip navigation link at top of every page

<a href="#main-content" class="sr-only focus:not-sr-only focus:fixed focus:top-4 focus:left-4 focus:z-50 focus:bg-white focus:px-4 focus:py-2 focus:rounded">
  Skip to main content
</a>

13. Publish an Accessibility Statement

The EAA requires organizations to publish an accessibility statement that declares conformance level, known issues, and a contact mechanism for accessibility feedback. Generate one at /tools/accessibility-statement.

14. Provide a feedback and enforcement mechanism

Users must have a way to report accessibility problems. The EAA also requires you to respond to requests for accessible alternatives within a “reasonable time.” Build in a contact email or form.

15. Run automated and manual testing before every major release

Automated tools catch about 30-50% of WCAG violations. Before any major feature ship, run a Certvo scan to catch regressions, then do a manual keyboard walkthrough of new flows.

Enforcement Timeline

The EAA became enforceable on 28 June 2025. However, most member states signaled a grace period for products already on the market before that date — those products had until June 2030 to comply. New products and services had to comply from day one (June 2025). If your website launched after June 2025, you should already be compliant. If it predates that date, you may technically have until 2030, but plaintiffs and advocacy groups are already filing complaints in Germany and France, so waiting is risky.

Quick Start

Start with a free Certvo scan to see where your site stands today. The report shows which WCAG criteria you are failing, prioritizes them by severity, and offers AI-generated code fixes for each one. Most teams get through the highest-priority fixes in a day or two. Ongoing monitoring ensures you stay compliant as your site evolves.