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

Imagine a world where every digital product is accessible to everyone, regardless of their abilities. This isn’t just a utopian vision – it’s a legal requirement under the European Accessibility Act (EAA).

On June 28, 2025, the way we build for the web will fundamentally change forever. As front-end developers, we’re standing at the forefront of this transformation. Let’s dive into what this means for us and how we can turn this challenge into an opportunity.

Table of Contents#

1. TL;DR
2. Yet Another Regulation?
3. European Accessibility Act: The Basics
4. WCAG 101
5. The Technical Side: What We Need to Build
6. Integrating a11y to Our Development Process
7. The Business Case: More Than Just Compliance
8. Leading the Change
9. Resources

TL;DR#

I know we are busy and this topic is definitely trending, so here is a quick summary of the key points you should now 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.
• 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 the state laws and can vary from a few thousands up to a 2% of the company’s annual turnover.

Technical Overview#

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

• Semantic HTML it’s 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#

• We can use EAA to build a11y awareness in our teams.
• This is a great opportunity to have some meaningful impact in our organizations.
• On the career side, driving the initiative can help you build yourself in your organization.

If you are interested in more detailed perspective, keep reading!

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.

To build a world where everyone can participate, we need a fundamental shift in how we approach these challenges, and we need to do it on a broad scale. I believe this transformation wouldn’t be possible without legal enforcement.

And trust me, I’m not putting on 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), enacted in April 2019, represents a landmark legislative effort to harmonize accessibility standards across the European Union (EU).
• By establishing unified requirements for digital and physical products and services, the EAA aims to dismantle barriers for over 80 million people with disabilities while fostering cross-border trade.
• 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?#

Here’s where it gets interesting. The EAA affects any digital product or service available to EU users – regardless of where your company is based. Yes, you read that right. If you’re a developer in San Francisco working on a product that Europeans can access, this applies to you as well.

• 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.

Penalties for Non-Compliance#

This is where the things go spicy as 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#

Now, let’s get to the meat of it – the actual implementation. The good news is that most of the time it’s just a matter of following best practices. Let’s break down the key areas where we need to focus our efforts.

1. 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>)

2. Keyboard Navigation: The Forgotten User Interface#

Here’s a sobering thought: many users can’t use a mouse. Every interactive element on your page needs to be accessible via keyboard. This means:

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.

3. 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>

4. 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.

5. 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

6. 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

Integrating a11y to Our Development Process#

Making accessibility part of your workflow is crucial for long-term success. Here’s how to build it into your team’s process from day one.

1. Shift Left: Start with Design#

Accessibility shouldn’t be an afterthought. Work with your design team to ensure:

• Color contrast is checked during design phase (use tools like Stark)
• 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.”

2. 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.

3. 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.

4. 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

5. Documentation and Knowledge Sharing#

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.

6. 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

Remember: Users with disabilities are the real experts. Their feedback is invaluable.

The Business Case: More Than Just Compliance#

Here’s something interesting: implementing accessibility often improves your SEO, makes your site more maintainable, and can even boost your conversion rates. Companies like Microsoft have 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, this is your moment to shine. Here’s your action plan:

1. Start the Conversation Share this article with your team. Organize a lunch-and-learn about accessibility. Make it relevant and personal.
2. Audit Your Current State Use tools like Lighthouse or WAVE to get a baseline of where you stand. The results might surprise you.
3. 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.

The Road Ahead#

The EAA isn’t just another regulation – it’s an opportunity to make the web better for everyone. As front-end developers, we have the power to shape this change. Yes, there will be challenges. Yes, it will take time to adapt. But the end result will be worth it: a more inclusive, accessible web for all users.

Remember: every line of code we write has the potential to either include or exclude users. Which will you choose?

Resources#

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

• An introduction to the European Accessibility Act by Derrin Evers
• Official EAA Documentation
• European_Accessibility_Act on Wikipedia
• WCAG 2.1 Guidelines
• A11y Project

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