The European Accessibility Act: A Front-End Developer's Guide

Preface

On June 28, 2025, a new EU regulation kicks in that will change how we build for the web. The European Accessibility Act (EAA) sets legal requirements for digital accessibility - and non-compliance comes with real penalties.

If you’re a front-end developer working on products available in the EU, this concerns you directly.

Quick Summary

Here’s a quick summary of the key points about the European Accessibility Act.

General Overview

The European Accessibility Act requires compliance with the WCAG 2.1 Level AA standards.
It applies to private and public entities offering hardware, digital products and services to EU users.
If your product is exclusively B2B, the EAA technically doesn’t apply. However, contractual obligations or national laws may still apply.
Key deadlines:
- By June 28, 2025: All new websites, apps, and features must comply.
- By June 28, 2030: All existing systems must comply.
There are different interpretations on how to treat changes in existing systems after June 2025.
- Most likely, if you add something not changing the flow (like a new post to existing blog) you should be fine.
- For a significant new feature, it must comply immediately.
Penalties for non-compliance depend on state laws and can vary from a few thousand up to 2% of the company’s annual turnover.

Technical Overview

What does it mean for us, front-end developers?

Semantic HTML is a must now, no more <div> pretending to be a <button>.
Our websites/apps should be accessible via keyboard, with logical tab order, visible focus indicators, and no keyboard traps.

Outcome for Leaders

The EAA gives you a concrete reason to push for a11y awareness in your team.
Driving this initiative can have real impact in your organization.
On the career side, being the person who led this effort looks good.

Yet Another Regulation?

First, let’s address the elephant in the room: another regulation, another set of requirements to juggle. Haven’t we got enough on our plates?

Well, saying that Europe is over regulated shouldn’t be very controversial or surprising. We have regulations for everything, from the curvature of bananas to the size of strawberries. While usually I’m very skeptical about any new law enforcements, I think this one is different.

The Moral Imperative

Public buildings nowadays have many features that help people with disabilities, such as ramps and special elevators. These have become so obvious that many people often do not pay attention to them anymore.

This wasn’t always the case.

Growing up in Eastern Europe, I can remember clearly how things were in the late 1990s and early 2000s. At that time, there were almost no facilities for disabled people in public places. The environment was very different from today, and even people without disabilities could sense the difference.

Then, accessibility features began appearing gradually. At the time, I didn’t grasp why, but now I see the answer was straightforward: legislation. It was the law that drove this transformation, making the world more inclusive for everyone.

So, fast-forward 20 years, and it’s time to ask:

Why don’t we apply the same standard to the digital world?

The Business Case

The harsh answer to the question is that it’s not just about morality. It’s also about money.

Building products to be accessible adds complexity to every stage of the creation. It requires investing time first in building awareness and competencies, then in designing products properly from the start - from user journeys to color contrast. Finally, we must integrate accessibility into the development process itself.

While those are easy to mitigate for the big tech companies, smaller businesses face greater challenges. The cost of implementing accessibility features can be significant for small businesses, and their hesitation is understandable. After all, they exist to create value and generate profit, and from a purely business perspective, accessibility investments may not always seem immediately justified.

But is a ramp in a public building justified if only one person a day uses it?

From a purely numerical perspective, the answer might seem obvious. Yet, despite how lyrical it sounds, this isn’t about money - it’s about humanity.

Making accessible products the default rather than the exception requires systemic change. And that kind of change doesn’t happen without regulation.

And trust me, I’m not putting on an a11y advocate hat here. To be fair, until recently, I didn’t pay much attention to accessibility unless it came as a side benefit of writing semantic HTML. However, I’m glad this will change now, not just for me but for all of us.

European Accessibility Act: The Basics

The best way to understand all the EU regulations is to read the official documentation. However, I know that it’s not always the most engaging read. So, let me bring the key points for you:

The European Accessibility Act (EAA) was enacted in April 2019 to standardize accessibility requirements across the EU.
It covers both digital and physical products and services, affecting over 80 million people with disabilities in Europe.
It applies to private and public entities offering hardware, digital products and services to EU users.
The EAA requires compliance with the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards. Scared about those acronyms? Don’t worry, we’ll get to them in a moment.
Microenterprises (fewer than 10 employees, less than €2M annual turnover) are exempt, though member states may impose stricter rules.

Should YOU Care?

The EAA affects any digital product or service available to EU users - regardless of where your company is based. If you’re a developer in San Francisco working on a product that Europeans can access, this applies to you too.

By June 28, 2025: All new websites, apps, and features must be accessible
By June 28, 2030: All existing systems must comply for accessibility

But here’s the twist that many developers miss:

If you add a significant new feature to an existing system after June 2025, that feature must comply immediately. You can’t hide behind the 2030 deadline.

So, yes, from now on we all should care and make accessibility a regular part of our development process.

B2B vs B2C: Understanding the Scope

An important clarification: the EAA primarily applies to consumer-facing (B2C) products and services. Under the directive, a “consumer” is defined as a natural person who purchases products or services for purposes outside their trade, business, craft, or profession.

If your product is exclusively B2B, the EAA technically doesn’t apply. However, your B2B clients may still require accessibility in contracts, and national laws may impose additional requirements. When in doubt, consult legal experts for your specific situation.

Penalties for Non-Compliance

This is where things get spicy - not complying with the EAA can result in fines. While they seem not as hard as for GDPR violations, they can still be significant. The fines can be up to 2% of the company’s annual turnover, which can be a significant amount for many businesses.

Non-compliance fines: €5,000-€20,000 per violation (e.g., missing alt text or keyboard navigation).
Daily penalties: Up to €1,000/day for unresolved issues.
Reputational risks: Public notices, exclusion from EU tenders, and lawsuits.

To be honest, this is still a little bit blurry to me, as it looks like penalties can vary from a few thousands up to a 300.000,00 EUR or more depending on circumstances and state laws. Probably not so much for a big corporation, but for a small business, it can be a significant amount.

However, going deeper into those aspects is beyond the scope of this article, but before we dive deeper into technicalities, here is an interesting article on Top Penalties for EAA Non-Compliance.

WCAG 101

The EAA requires compliance with WCAG 2.1 Level AA standards. WCAG stands for Web Content Accessibility Guidelines - a set of specific criteria for making web content accessible to everyone.

Understanding WCAG Levels

WCAG has three conformance levels:

Level A: Basic accessibility (minimum requirements)
Level AA: The global standard (50 success criteria total, including all of Level A)
Level AAA: Enhanced accessibility (primarily for specialized applications)

The EAA mandates Level AA compliance, which is the industry standard for most websites and applications.

The Four Principles of WCAG

These guidelines are built on four core principles (often abbreviated as POUR):

Perceivable: Information must be presented in ways all users can perceive (e.g., alt text for images, captions for videos).
Operable: Interfaces must be usable via keyboard and other assistive technologies.
Understandable: Content should be clear and predictable (consistent navigation, clear error messages).
Robust: Websites must work well with current and future assistive technologies.

A Practical Example

Let’s look at a concrete example. WCAG Guideline 1.2 (Time-based media) states: “Provide alternatives for time-based media.”

One specific success criterion is 1.2.2 Captions (Prerecorded) - Level A: “Captions are provided for all prerecorded audio content in synchronized media.”

In practice: If you have a video on your site, you need to provide captions for the spoken content. This helps deaf and hard-of-hearing users understand the video, but it also benefits users in noisy environments or those who prefer reading.

At the time of writing, WCAG 2.1 is the current standard, with version 2.2 available but not yet required by the EAA.

Now that we understand what WCAG is, let’s discuss what this means for us as front-end developers.

The Technical Side: What We Need to Build

Time for the actual implementation. The good news: most of this is just following best practices you probably already know.

Semantic HTML: The Foundation

This is non-negotiable now. Using the right HTML element for the job isn’t just about clean code - it’s about accessibility.

Bad example:

<div onclick="handleClick()">Click me</div>

Good example:

<button onclick="handleClick()">Click me</button>

Why? Because a proper <button> element:

Is automatically keyboard accessible
Announces itself correctly to screen readers
Has built-in focus management
Supports native browser behaviors

Key semantic elements to use:

<header>, <nav>, <main>, <footer> for page structure
<article>, <section>, <aside> for content organization
<button> for actions, <a> for navigation
<label> for form inputs
Proper heading hierarchy (<h1> through <h6>)

Many users can’t use a mouse. Every interactive element on your page needs to be accessible via keyboard:

Essential requirements:

Logical tab order: Users should move through interactive elements in a predictable sequence
Visible focus indicators: Make it crystal clear which element has focus (avoid outline: none unless you provide a better alternative)
No keyboard traps: Users should always be able to navigate away from any element
Skip links: Allow users to bypass repetitive navigation

Quick test: Try navigating your site using only the Tab, Shift+Tab, Enter, and Arrow keys. If you get stuck or lost, so will your users.

ARIA: Use When Needed, Not by Default

ARIA (Accessible Rich Internet Applications) attributes help make complex interfaces accessible. However, there’s a crucial rule:

The first rule of ARIA: Don’t use ARIA unless you have to.

When to use ARIA:

When semantic HTML isn’t enough (complex widgets like tabs or accordions)
To provide additional context (aria-label, aria-describedby)
For dynamic content updates (aria-live)
To indicate states (aria-expanded, aria-pressed)

Example of good ARIA usage:

<button aria-expanded="false" aria-controls="menu">Menu</button>
<nav id="menu" aria-hidden="true">
  <!-- navigation items -->
</nav>

Color and Contrast: Make It Readable

Color contrast is critical. WCAG 2.1 Level AA requires:

4.5:1 contrast ratio for normal text
3:1 contrast ratio for large text (18pt+ or 14pt+ bold)
3:1 for UI components and graphical objects

Tools to check:

Chrome DevTools (built-in contrast checker)
WebAIM Contrast Checker
Lighthouse accessibility audit

Important: Never rely on color alone to convey information. If you highlight errors in red, also include an icon or text label.

Alternative Text and Media

Every image needs alternative text. But not all alt text is created equal:

Decorative images:

<img src="decorative-border.png" alt="" />

Informative images:

<img src="chart.png" alt="Sales increased by 50% in Q4 2024" />

For videos:

Provide captions for all spoken content
Include audio descriptions for important visual information
Offer transcripts when possible

Forms: The Critical Touchpoint

Accessible forms are essential, especially for e-commerce and services:

Must-haves:

<form>
  <label for="email">Email address</label>
  <input type="email" id="email" name="email" aria-required="true" aria-describedby="email-error" />
  <span id="email-error" role="alert">
    <!-- Error message appears here -->
  </span>
</form>

Key principles:

Every input needs a <label> associated with it
Group related inputs with <fieldset> and <legend>
Provide clear error messages and associate them with the relevant field
Indicate required fields programmatically
Don’t rely on placeholders as labels

Accessibility can’t be an afterthought if you want it to stick. Here’s how to build it into your team’s process.

Shift Left: Start with Design

Work with your design team to ensure:

Color contrast is checked during design phase
Focus states are designed, not just assumed
Interactive elements are large enough (minimum 44×44 pixels for touch targets)
User flows consider keyboard-only navigation

Pro tip: Include accessibility acceptance criteria in your user stories. For example: “As a keyboard user, I can navigate the entire checkout flow using only Tab, Shift+Tab, and Enter keys.”

Automated Testing: Your First Line of Defense

Automation can catch many issues early. Integrate these tools into your pipeline:

During development:

eslint-plugin-jsx-a11y for React projects
axe DevTools browser extension
Lighthouse CI in your build process

Example GitHub Actions workflow:

name: Accessibility Check
on: [pull_request]
jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Lighthouse CI
        uses: treosh/lighthouse-ci-action@v9
        with:
          configPath: './lighthouserc.json'

Important caveat: Automated tools catch only ~30-40% of accessibility issues. They’re necessary but not sufficient.

Manual Testing: The Human Element

Some things require human judgment:

Weekly routine:

Navigate your application using only the keyboard
Test with a screen reader (VoiceOver on Mac, NVDA on Windows)
Check your site at 200% zoom
Test with browser extensions that simulate color blindness

Screen reader testing basics:

Mac: VoiceOver (Cmd+F5 to enable)
Windows: NVDA (free) or JAWS (commercial)
Mobile: TalkBack (Android) or VoiceOver (iOS)

Don’t be intimidated by screen readers. Start with basic navigation and gradually build your skills.

Code Review Checklist

Add accessibility to your code review process:

All interactive elements are keyboard accessible
Focus indicators are visible
Images have appropriate alt text
Form inputs have associated labels
Color isn’t the only way to convey information
Dynamic content updates are announced to screen readers
Heading hierarchy is logical

Build institutional knowledge:

Create an accessibility wiki for your team
Document common patterns and solutions
Share learnings from user testing sessions
Celebrate accessibility wins in team meetings

Recommended practice: Assign an “a11y champion” for each sprint or project. This person becomes the go-to expert and helps ensure nothing slips through the cracks.

User Testing with Real Users

Nothing beats testing with actual users who rely on assistive technologies:

Partner with disability advocacy organizations
Offer paid testing sessions for users with disabilities
Incorporate accessibility feedback into your product roadmap

Users with disabilities are the real experts here. Their feedback will show you problems you never knew existed.

The Business Case: More Than Just Compliance

Implementing accessibility often improves your SEO, makes your site more maintainable, and can boost conversion rates. Microsoft has reported that their accessible products have higher customer satisfaction rates across all users, not just those with disabilities.

Leading the Change

If your organization hasn’t started preparing for the EAA yet, here’s a practical action plan:

Start the Conversation Share this article with your team. Organize a lunch-and-learn about accessibility. Make it relevant and personal.
Audit Your Current State Use tools like Lighthouse or WAVE to get a baseline of where you stand. The results might surprise you.
Make It Part of Your Process Add accessibility checks to your code reviews. Include it in your definition of done. Make it as fundamental as testing or performance.

Resources

Here are some of the resources I used preparing this article:

This article was written based on the EAA legislation as of February 2025. Requirements may evolve as implementation details are clarified.