Laurent Thiebault
Back to blog

European Accessibility Act: Last call for teams!

June 24, 2025 (2w ago) • 2,985 words • 15 min read

European Accessibility Act: Last call for teams!

June 28, 2025 is almost here. If you work in marketing, tech, design, or product, you’ve probably heard the rumblings: the European Accessibility Act (EAA) is about to become enforceable. If you haven’t, well... surprise! It’s time to make your digital products accessible—or risk legal headaches, unhappy users, and a lot of facepalms in your next retro.

But don’t panic. Whether you’re audit-ready, still waiting for results, or just realized you need to do something (anything!), this guide is for you. I’ll share my best, most actionable tips to help your team get ready—fast. Plus, I’ve curated the best resources, tools, and checklists to make accessibility less scary and a lot more doable.

TL;DR: The essentials

  • EAA enforcement starts June 28, 2025
  • Applies to most digital products and services in the EU
  • Accessibility isn’t just a checkbox—it’s about real people
  • You'll find 10 actionable quick wins in this article
  • You don’t need to be a WCAG wizard to make a big difference
  • Start with simple checks, use the right tools, and iterate

What is the European Accessibility Act (EAA)?

The EAA is a European Union directive that aims to make key digital products and services accessible to everyone—including the millions of Europeans with disabilities. It covers everything from websites and mobile apps to e-commerce, ATMs, e-books, ticketing machines, and more. If you sell, build, or maintain digital products in the EU, this law probably applies to you.

Why care? (Besides the Law)

  • 1 in 5 people has some form of disability (around 87 million people). Accessibility = inclusivity = more users
  • Accessible products are better for everyone (think: keyboard shortcuts, readable text, clear forms)
  • Finally, that's als good for business, SEO, and your conscience

What’s new?

  • The EAA is not just for public sector: it’s for private companies too.
  • It’s not just about websites: it’s about the whole digital experience.
  • It’s enforceable: non-compliance can mean fines, lawsuits, and public shaming (nobody wants to trend on X for the wrong reasons).

Who needs to comply?

  • E-commerce sites
  • Banking and financial services
  • Transport and ticketing
  • E-books and e-readers
  • Telecoms
  • ATMs, ticketing and check-in machines
  • And more (see the official list)

What do you need to do?

  • Meet the accessibility requirements (think: WCAG 2.2 AA, but check your country’s specifics)
  • Provide information in accessible formats
  • Ensure customer support is accessible

Pro tip: Even if you’re not in the EU, if you serve EU customers, the EAA can still apply to you.

Accessibility myths busted

Let’s clear up some common misconceptions before they trip you up:

  • “Accessibility is for blind users, right?” Nope, not only! It’s for people with visual, auditory, motor, cognitive, and even temporary disabilities (think: broken arm, noisy commute, bad Wi-Fi, etc.).
  • “It’s too expensive.” Not as expensive as a lawsuit—or losing customers. Most fixes can be cheap if you start early.
  • “We’ll do it later.” Later = never. The longer you wait, the harder (and pricier) it gets.
  • “Automated tools catch everything.” They don’t. Manual testing is essential.
  • “Accessible = ugly.” Modern design systems make accessible products beautiful. Just look at Apple, GOV.UK, or Airbnb.

Don’t be that team: The one that waits until the last sprint to “add accessibility.” It’s like trying to add eggs after the cake is baked.

Deep dives: how to nail each quick win

Before we dive in, a quick disclaimer: I’m not claiming to be an accessibility expert. I’m doing my best to share practical, concrete, and immediately actionable tips—drawn from both experience and research.

If you have feedback, questions, or additional tips to share, feel free to drop a comment or reach out—I’d love to hear from you. The goal here is simple: help as many teams as possible take real steps forward, without getting lost in theory or paralyzed by the fear of doing it wrong.

Let’s move forward together!

1. Forms

Why it matters: Forms are everywhere—and they’re often the most frustrating part of the web for users with disabilities.

How to check:

  • Try filling out forms with only a keyboard
  • Use a screen reader to submit a form with errors

What to do:

  • Every input needs a <label> (linked with for and id)
  • Required fields should be clearly marked
  • Error messages should be specific, visible, and announced by assistive tech
  • Give clear instructions for formats (e.g., date, phone)

Example:

<label for="email">Email</label>
<input id="email" name="email" type="email" required />
<span class="error" id="email-error">Please enter a valid email address.</span>

Useful resource: W3C WAI - Forms Tutorial

Watch out: Don’t use placeholder text as a label. And don’t put error messages after the form—they should be before or next to the field.

2. Keyboard navigation

Why it matters: Many users rely on keyboards (not just screen readers!). If you can’t tab to something, it might as well not exist.

How to check: Try tabbing through your site. Is the focus visible? Can you reach all interactive elements? Can you escape popups?

Example:

  • Focus outlines should be clear (don’t remove them with outline: none;)
  • Modals should trap focus, but let you escape with Esc

Tools: taba11y - Tab order accessibility testing

Watch out: Don’t create “keyboard traps” (where you can’t tab out of a modal or menu).

3. Headings

Why it matters: Headings help everyone scan and understand content. For screen reader users, headings are the main way to navigate a page.

How to check:

  • Use browser dev tools or accessibility tree to inspect heading order
  • Try navigating by headings with a screen reader

What to do:

  • Use one <h1> per page (usually the page title)
  • Don’t skip levels (e.g., don’t jump from <h1> to <h3>)
  • Use headings for structure, not just for styling

Example:

<h1>Checkout</h1>
<h2>Shipping Address</h2>
<h2>Payment Method</h2>

Tools: HeadingsMap browser extension

Watch out: Don’t use headings for layout only. And don’t hide headings visually if they’re needed for structure.

4. Image alternative text

Why it matters: Alt text is read by screen readers and displayed if images fail to load. It's essential for users who can't see images.

How to check:

  • Inspect images in your code or browser dev tools
  • Use automated tools to flag missing alt attributes

What to do:

  • Only add descriptive alt text when images convey meaningful information
  • Describe the function, not just the appearance (e.g., "Company logo" not "Blue circle")
  • Decorative images? Use alt="" so screen readers skip them
  • Don't stuff keywords—write for humans

Example:

  • <img src="logo.png" alt="Acme Corp logo">
  • <img src="wave.png" alt=""> (decorative)

Useful resource: W3C WAI - Alt Decision Tree

Watch out: Don't use the filename as alt text. And don't repeat the same alt text everywhere.

5. Color contrast ratio

Why it matters: Low color contrast = unreadable for many users (and for everyone in sunlight!).

How to check:

  • Use a contrast checker on all text/background pairs
  • Test in light and dark mode

What to do:

  • Text should have at least 4.5:1 contrast (3:1 for large text)
  • Don’t rely on color alone to convey information

Example:

  • Black text on white: good
  • Light gray on white: bad

Tools: WebAIM Contrast Checker, ColorBox

Watch out: Don’t use color as the only way to show errors or status. Use text too.

6. Mobile adaptability

Why it matters: Over 50% of web traffic is mobile. Many users with disabilities rely on mobile assistive tech (screen readers, switch controls, voice input).

How to check:

  • Resize your browser window
  • Test on real devices (not just emulators)
  • Try with screen orientation changes

What to do:

  • Make sure all content is visible and usable at all breakpoints
  • Interactive elements should be easy to tap (minimum 44x44px)
  • No horizontal scrolling required

Example:

  • Can you fill out a form on your phone with one hand?
  • Are buttons and links spaced far enough apart?

Useful resource: Responsive Web Design: How it Relates to Digital Accessibility by Level Acccess

Watch out: Don’t hide important content on mobile! And don’t forget landscape mode.

7. Screen reader support

Why it matters: Screen readers are used by millions of people—blind, low-vision, dyslexic, or just multitasking. If your app works with a screen reader, it’s a huge step toward true accessibility.

How to check:

What to do:

  • Navigate your site/app with the screen reader only (no mouse!)
  • Listen for clear announcements of headings, links, buttons, and error messages
  • Try completing a key user flow (e.g., checkout, sign-up)

Example:

  • Does your error message get announced when a form fails?
  • Are all buttons and links described meaningfully (not just “Click here”)?

Useful resource: Screen Reader Testing Guide

Watch out: Don’t rely on ARIA for everything. Use semantic HTML first!

8. Zoom settings compliance

Why it matters: Many users zoom text or use large fonts. If your layout breaks, content overlaps, or things disappear, it’s a problem.

How to check:

  • Zoom your browser to 200% and 400%
  • Increase text size in OS/browser settings

What to do:

  • Use relative units (em, rem, %) for layout and font sizes
  • Make sure all content is still visible and usable
  • No horizontal scrolling required

Example:

  • Can you read all the text at 200% zoom?
  • Are buttons and inputs still usable?

Useful resource: W3C WAI - Zoom Levels - Easy Checks

Watch out: Don’t use fixed heights for containers. And don’t hide overflow content.

9. Motion settings compliance

Why it matters: Fast movement or flashing can trigger seizures or make content unusable for some users.

How to check:

  • Look for carousels, auto-updating content, or flashing banners
  • Test with reduced motion settings in your OS

What to do:

  • Allow users to pause, stop, or hide moving content
  • Never flash more than 3 times per second
  • Respect prefers-reduced-motion CSS media feature

Example:

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.001ms !important;
    transition-duration: 0.001ms !important;
  }
}

Useful resource: Google Chrome - Emulate CSS media features

Watch out: Don’t autoplay videos with sound. And don’t use flashing ads or banners.

10. Video & audio alternatives

Why it matters: Videos and audio need captions, transcripts, and controls for everyone to access the content.

How to check:

  • Play all videos and audio—are captions and transcripts available?
  • Can you control playback with keyboard and mouse?

What to do:

  • Provide accurate captions (not just auto-generated)
  • Offer transcripts for audio content
  • Don’t autoplay media with sound

Example:

  • YouTube videos with real captions
  • Podcast episodes with full transcripts

Tools: W3C WAI - Making Audio and Video Media Accessible

Watch out: Don’t rely on YouTube’s auto-captions alone. And don’t hide media controls.

Advanced accessibility: go beyond the basics

Accessibility in single-page apps (SPAs)

Modern web apps are often built as SPAs (React, Vue, Angular, etc.), but these can be a nightmare for assistive tech if not handled right. Why? Because content changes without a full page reload, and screen readers may not notice!

What to do:

  • Use ARIA live regions to announce dynamic content changes (e.g., form errors, notifications)
  • Update the document title and focus when navigating between views
  • Use semantic HTML for all interactive elements (not just <div>s with click handlers)
  • Test with real screen readers after every major change

Resources:

Accessibility in design systems

A design system is only as good as its accessibility. If your components aren’t accessible, every product built with them will have the same issues—at scale.

What to do:

  • Document accessibility requirements for every component (focus, keyboard, ARIA, color contrast)
  • Provide accessible defaults (e.g., always include labels, use semantic elements)
  • Test components in isolation and in real user flows
  • Train your team: designers, devs, and PMs

Resources:

Automatic checks with tools

Why it matters: Automated tools catch the obvious stuff—missing alt text, low contrast, bad ARIA, etc.—before it hits production.

How to check: Integrate axe-core, Lighthouse, Accessibility testing with Playwright, or SonarQube Cloud into your CI/CD pipeline. Run them locally, too.

Watch out: These tools can’t catch everything (like bad alt text or keyboard traps). Always combine with manual testing.

Accessibility for mobile apps

Mobile accessibility is not just about responsive web. Native apps (iOS, Android) have their own requirements and tools.

What to do:

  • Use platform accessibility APIs (VoiceOver for iOS, TalkBack for Android)
  • Label all controls and images
  • Support dynamic type and system font scaling
  • Test with real users and assistive tech

Resources:

Internationalization and accessibility

Accessibility isn’t just for English speakers. Multilingual sites need to:

  • Set the correct lang attribute on every page
  • Translate alt text, form labels, and error messages
  • Make sure screen readers announce content in the right language

Resource: W3C: Using the language attribute on the HTML element

Building an accessibility culture

Make it everyone’s job

Accessibility isn’t just for the “a11y expert” or the QA team. It’s a team sport. The best teams:

  • Add accessibility to their Definition of Done
  • Review accessibility in every code review
  • Celebrate accessibility wins in retros
  • Share user feedback and real stories

Train and empower

  • Run regular accessibility workshops (invite users with disabilities!)
  • Share resources and checklists
  • Nominate accessibility champions in every squad

Accessibility audits: what to expect

What is an audit?

An accessibility audit is a structured review of your product against standards like WCAG 2.1 AA. It can be done by internal teams or external experts.

What happens:

  • Automated and manual testing
  • User testing with assistive tech
  • Detailed report with issues, severity, and recommendations

How to prepare

  • Run your own checks first (see above!)
  • Document known issues and your roadmap to fix them
  • Make sure your team is available to answer questions

What if you fail?

  • Don’t panic. Most teams have issues at first.
  • Prioritize fixes by severity and user impact
  • Communicate transparently with stakeholders

Resource: W3C: Evaluating Web Accessibility Overview

FAQ: your burning accessibility questions

Q: Is accessibility really required by law?

A: Yes. In the EU, the EAA is enforceable from June 28, 2025. In the US, the ADA and Section 508 apply. Many other countries have similar laws (W3C: Policies).

Q: What’s the best way to get started?

A: Start with the basics: keyboard, forms, contrast, alt text. Use checklists and tools, but always test with real people.

Q: How do I convince my team or boss?

A: Show the real case, share user stories, and remind them: lawsuits are expensive, but happy users are priceless.

Q: Is accessibility just for web?

A: No! It applies to mobile, desktop, kiosks, ATMs, e-books, and more.

Q: Where can I learn more?

A: See the resources section above, and follow experts resources like WebAIM, Deque, and W3C WAI.

Recap

If you're looking for a great recap of this topic, I highly recommend Robin Kanatzar's excellent talk below. It covers the European Accessibility Act essentials in a clear, engaging way—perfect if you prefer video format or want to share these concepts with your team:

The future: beyond EAA 2025

Accessibility is not a one-time project. Standards evolve (WCAG 2.2, 3.0 in draft), tech changes, and user needs shift. AI is starting to help (see Microsoft's Seeing AI project, but human empathy and testing will always matter.

Keep learning, keep testing, and keep listening to users.

References

Special thanks

A big thank you to my colleagues Marie, Thibault, and Gaspard from Decathlon Digital's Special Interest Group about Digital Accessibility. It’s thanks to their long-standing commitment, the many discussions we’ve had, and their generous pedagogy that I’ve been able to grow and deepen my understanding of accessibility over the years. Their work doesn’t just improve our products at Decathlon, it elevates all of us.

If you made it this far, you’re already ahead of most teams. Go make something everyone can use—and let me know if you have questions, feedback, or want to share your own accessibility journey!

Comments

LinkedIn
X

Command Palette

Search for a command to run...