The Developer's Guide to the European Accessibility Act

Let me be direct about something most accessibility articles dance around: most web applications are inaccessible to a significant portion of their users right now. Not because developers are malicious, but because accessibility wasn't built into the process. The European Accessibility Act is the legal mechanism that's forcing that to change.

If you're building or maintaining digital products for the European market — and that includes products from outside the EU if they serve EU consumers — this affects you. The enforcement date of June 28, 2025 has passed. Which means if you're reading this and haven't started, you're already behind.

Here's what you actually need to know.

What the EAA Is (And Isn't)

The European Accessibility Act (Directive 2019/882) is binding EU law. Not a guideline. Not a recommendation. Law, enforceable across all 27 EU member states, with penalties that vary by country but can be significant.

A key thing developers often miss: this primarily targets private sector businesses. Previous EU accessibility law focused on public sector websites. The EAA brings the same requirements to commercial products.

Who's Affected

Products covered: - Computers and operating systems - Smartphones and tablets - E-readers - Self-service terminals (ATMs, ticketing machines) - Consumer electronics (smart TVs, streaming devices)

Services covered: - E-commerce (your online shop, your checkout flow) - Online banking and financial apps - Electronic communications (messaging apps, VoIP) - Transport booking websites - E-book platforms and streaming services

If you're a small company: There's an exemption for microenterprises providing services (under 10 employees, under €2M annual turnover). But document your assessment — the exemption isn't automatic, and you still need to have thought through whether it applies.

If you're outside the EU: The EAA applies to you if EU consumers use your product. The EU has been quite clear about extraterritorial application.

What WCAG 2.1 AA Actually Requires in Practice

The EAA points to EN 301 549, which for web content aligns with WCAG 2.1 Level AA. Let me translate the abstract principles into things you need to actually build:

Images need text alternatives

```html <!-- Don't do this --> <img src="product.jpg">

<!-- Do this --> <img src="product.jpg" alt="Red wireless headphones with noise cancellation, shown from the left side">

<!-- Decorative images get empty alt --> <img src="decorative-line.png" alt="" role="presentation"> ```

Forms need proper labels (not just placeholders)

```html <!-- This is not accessible --> <input type="text" placeholder="Email">

<!-- This is --> <label for="email">Email Address</label> <input type="email" id="email" name="email" autocomplete="email" aria-describedby="email-hint" required > <span id="email-hint">We'll never share your email with anyone</span> ```

Placeholder text disappears when someone starts typing. It's not a substitute for a label. This trips a lot of teams up.

Interactive elements must be keyboard-accessible

```html <!-- This is invisible to keyboard users and screen readers --> <div onclick="submitForm()">Submit</div>

<!-- Use semantic HTML instead --> <button type="submit" aria-label="Submit contact form"> Submit </button> ```

Color contrast matters more than you think

Normal text needs a 4.5:1 contrast ratio with its background. Large text (18pt+ or 14pt bold) needs 3:1. Light gray text on white backgrounds — extremely common in modern design — almost always fails this.

There's a quick test: WebAIM Contrast Checker. Run your main text colors through it before anything else.

Add a skip navigation link

```html <!-- First element in body --> <a href="#main-content" class="skip-link"> Skip to main content </a>

<style> .skip-link { position: absolute; top: -40px; left: 0; padding: 8px; background: #000; color: #fff; z-index: 100; } .skip-link:focus { top: 0; } </style> ```

This is invisible to most users but essential for keyboard-only navigation. Screen reader users and power keyboard users rely on it.

The Four WCAG Principles (What They Mean Concretely)

Testing Tools That Actually Help

Don't rely on a single automated tool. Automated testing catches maybe 30% of accessibility issues — the mechanical stuff. The rest requires manual testing and real users.

For CI/CD integration: ``bash npm install -g pa11y pa11y --standard WCAG2AA https://your-website.com ``

The Accessibility Statement Requirement

Under the EAA, you must publish an accessibility statement on your site. It needs to include:

• Your current compliance status (full, partial, or non-compliant with EN 301 549)
• What's not accessible and why
• How users can get information through alternative means
• A way to report accessibility issues
• When the statement was last updated

This isn't optional — it's a legal requirement. And it signals to users that you've actually thought about this.

Penalties: What's Actually at Risk

Beyond fines: litigation from disability rights organizations, reputational damage, and lost customers who simply can't use your product. The 1-in-6 people globally who have some form of disability represent real revenue you're leaving on the table.

Where to Start If You're Behind

If I had to pick the highest-impact fixes that are also quick to implement:

1. Alt text on all images — High impact, low effort. Can be done in a day.
2. Fix color contrast — Run your palette through WebAIM. Adjust text colors.
3. Proper form labels — Replace placeholder-only inputs with actual labels.
4. Keyboard navigation audit — Tab through your entire app. Note where focus gets stuck or disappears.
5. Skip navigation link — 20 minutes to implement, meaningful impact for keyboard users.
6. Publish an accessibility statement — Even if you're not fully compliant yet, document what you know and what you're working on.

The goal isn't perfection from day one. It's demonstrable, good-faith effort with a clear plan.