
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 withfor
andid
) - 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:
- On Mac: You can try VoiceOver (
Cmd + F5
) - On Windows: You can try NVDA or JAWS
- On mobile: You can try TalkBack (Android) or VoiceOver (iOS)
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:
- Sitepoint - Accessibility Best Practices for Single Page Applications (SPAs)
- MDN - ARIA live regions
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:
- 7 Ways to Make Accessibility Work in Your Design System by Into Design Systems
- WCAG 2.2 Card Deck by Johannes Lehner
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:
- The Luxembourg Government - Mobile App Accessibility Assessment Framework (RAAM)
- Apple Accessibility
- Android Accessibility
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
- W3C: Web Content Accessibility Guidelines (WCAG) 2.2
- W3C WAI: Accessibility Fundamentals
- W3C WAI: Tips for Writing
- W3C WAI: Tips for Designing
- W3C WAI: Tips for Developing
- W3C WAI: Audio & Video Media guidelines
- W3C WAI: Tutorials for page structure, menus, images, tables, forms & carousels
- W3C WAI: ARIA Authoring Practices Guide (APG) - Patterns
- W3C WAI: Laws & Policies relating to accessibility
- W3C WAI: How to Conduct an Accessibility Evaluation
- CDC: Disability Impacts All of Us
- Return on Disability: The Global Economics of Disability Report 2024
- Deque: Accessibility tips in Single-Page Applications
- Apple: Accessibility
- Android: Accessibility
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!