Accessibility isn’t optional anymore — and ignoring it is starting to cost real money
The EU Accessibility Act went into effect on June 28, 2025, and enforcement is no longer theoretical. France has filed its first EAA lawsuits, a French court has already ordered Carrefour to fix its site and app or face daily fines, and German e-commerce sellers have started receiving legal warning letters.
If you sell software in the EU (European Union), you’re expected to comply, whether or not you’ve done anything about it.
But here’s the problem: most makers still think accessibility is “just for screen readers” or something you dealt with once and can forget. That mindset has become risky. Failing to meet the standards can lead to legal consequences, lost users, and a product that silently shuts people out.
To help you understand the importance of complying with the EAA, we spoke with Chris Hinds, COO at Equalize Digital. Together with CEO Amber Hinds (who’s also his wife), he’s on a mission to make accessibility more achievable for software makers.
Let’s get started.
TL;DR: Does the European Accessibility Act (EAA) apply to you, and what do you do about it?
- EU Accessibility Act applies to you if you sell software, SaaS, WordPress plugins, an app, or any other consumer-facing digital product to customers in the EU, regardless of where your business is based.
- You may be exempt if you’re a microenterprise (fewer than 10 employees and under €2 million in annual turnover), but this exemption is narrow and doesn’t cover product makers.
- What to do: audit your product against WCAG 2.1 AA, fix the highest-impact issues first (alt text, heading structure, contrast, keyboard navigation, form labels), and check whether tools you already use, like Freemius Checkout and Customer Portal, have already handled part of this for you.
What is the EU Accessibility Act and who’s affected?
The EU Accessibility Act (EAA) is a law designed to ensure that key products and services are usable by people with disabilities. It sets accessibility requirements for digital products sold or used in the EU, including websites, mobile apps, e-books, and software platforms.
If you build or sell software, especially if it’s consumer-facing (like SaaS tools, plugins, or digital services), this applies to you.
Key deadlines:
- The law took effect on June 28, 2025, and has been enforceable across all 27 EU member states since then.
- Products and services released after that date had to comply immediately, unless they qualify for exemptions (like being a microenterprise).
- If you’re selling something that was already on the market before June 28, 2025, you have until June 28, 2030 to bring it into compliance, unless you replace or materially change it sooner.
What does “accessible” mean in practice?
In the context of the EU Accessibility Act, “accessible” means that your software can be used by as many people as possible, including those with visual, auditory, motor, and cognitive disabilities. This goes beyond just screen reader compatibility.
For digital products, accessibility is defined primarily by Web Content Accessibility Guidelines (WCAG) 2.1 AA standards. These include practical requirements that go beyond an interface that doesn’t break when you zoom in. The EAA frames these as functional requirements rather than a specific line of code: what matters is functional accessibility for the end user, not any one implementation.
Chris says that many developers he speaks with understand the need to test “how an interface behaves when using only a keyboard, or zooming their browser in to 200-400%. What is far less common is considering what a particular web page or application sounds like on a screen reader like NVDA or Voice Over.”
Here are some WCAG 2.1 AA requirements:
- Keyboard navigation: All functionality should be usable without a mouse.
- Text alternatives: Images, icons, and non-text content must have meaningful alt text.
- Sufficient contrast: Text must have enough color contrast against the background to be readable.
- Consistent structure: Use proper headings (H1, H2, etc.), labels, and navigation so users can understand and move through your product easily.
- Error identification and suggestions: If a user makes a mistake in a form, the issue must be clearly explained and guidance offered.
- Resizable text and adaptable layout: Users should be able to zoom or use custom styles without breaking your layout.
- Captions and transcripts: Audio & visual media services should include captions or transcripts for users who are deaf or hard of hearing.
There are also myths about what accessibility really is. Chris shared two of the most common ones that are holding software makers back:
“One is that accessibility costs too much. The reality is that if you’ve already adopted a mindset of continuous improvement around other facets of your software product (like performance, or security), you can do the exact same thing with accessibility,” explains Chris, and adds that many automated accessibility scanning tools are extremely cost-effective.
“Even if you have a tiny QA team, they can learn accessibility testing with screen readers in as little as 6-8 hours. If you are adding a new feature, or re-working an old one, start by making sure that any new code you ship is accessible.”
Source: Equalize Digital
The second myth has likely been exacerbated by “vibe coding” and AI trends, and the data backs Chris up: WebAIM’s 2026 Million report found that 95.9% of the top one million home pages still have detectable WCAG failures, up from 94.8% the year before.
It’s the first year-over-year regression after six straight years of slow improvement, and WebAIM points to rising page complexity and increased reliance on automated AI-assisted coding as key drivers. According to Chris, it’s “garbage in, garbage out”:
“When 95% of the web is failing basic accessibility checks, it’s not a stretch to conclude that AI models built on the same data will consistently fail to generate accessible product code. Our team frequently uses AI in our own work, and the #1 priority is to ensure accessibility in the code and content generated by AI. While there are conversations around synthesizing large sets of “accessible” code/data to create models that will generate accessible outputs by default, evidence suggests it’s a very long way off.”
What do EAA requirements actually involve
EAA compliance isn’t just about making your code accessible. If your business falls under the European Accessibility Act, you may also have documentation, disclosure, and ongoing compliance responsibilities.
Here are the main requirements software makers should know about.
The technical standard
EN 301 549 is the main European accessibility standard used to assess compliance with the EAA. It currently incorporates WCAG 2.1 AA in full.
A new version, EN 301 549 v4.1.1, is expected later in 2026 and is expected to incorporate WCAG 2.2. If you’re working on accessibility now, it’s worth building toward WCAG 2.2 rather than stopping at 2.1 AA.
The accessibility statement
If you provide a covered service, accessibility doesn’t stop at your product. You also need to provide a public accessibility statement that explains:
- Which accessibility features your service supports
- How the service meets the applicable accessibility requirements
- Any known accessibility issues or limitations
- How users can report accessibility problems
Some EU countries may have additional national requirements, such as asking businesses to identify the authority responsible for accessibility enforcement.
The disproportionate burden exemption
The EAA allows businesses to claim that a specific accessibility requirement would create a disproportionate burden or fundamentally change the nature of their product or service.
This isn’t a general exemption from the EAA. You need to document why the requirement would create a disproportionate burden, based on the criteria in Annex VI.
You must also keep this documentation for five years and reassess it when necessary. If the exemption applies, it only covers the specific requirement in question. The rest of your accessibility obligations still apply.
The microenterprise exemption
Microenterprises can be exempt from some EAA requirements for services.
To qualify, a business generally needs to have:
- Fewer than 10 employees
- Annual turnover or a balance sheet total of no more than €2 million
The exemption applies to services, not covered products. So a small business isn’t automatically exempt from every EAA requirement.
Who enforces the EAA?
Each EU country has its own authorities responsible for enforcing the EAA under national law.
These authorities can request compliance documentation, require businesses to fix accessibility problems, and in some cases restrict or withdraw non-compliant products or services from the market.
This is different from the EU Web Accessibility Directive, which focuses on public-sector websites and apps. The EAA also covers certain private-sector products and services.
What the EAA means for software makers
If you’re building SaaS, plugins, or any kind of digital product used in the EU, the EU Accessibility Act applies to you.
This isn’t just a concern for large companies. Solo makers and small teams are on the hook, too, and failing to comply could lead to:
- Legal complaints or product removal from the EU market
- Damage to your brand’s reputation
- Lost sales and support overhead from frustrated users
None of that is hypothetical anymore. Fines now range from €60,000 in Ireland to over €1.2 million in Hungary, and in June 2026 a French court ordered Carrefour to fix both its e-commerce site and app within six months or pay a daily fine.
Many software makers are surprised to learn how much they can uncover during a simple accessibility audit.
“The number of accessibility barriers our testers can identify during an accessibility audit of websites or products. These are not trivial issues. I’m talking about issues that will fully block or lock out certain users, or (at best) are tanking their conversion and engagement rates.”
Luckily, Chris highlights, many of these issues are easy fixes once you recognize them and see why they’re a problem:
“When we do this work with clients, we take the time to explain everything so that they understand the “why” – And it is always gratifying to see when it clicks for them, and they understand how important these improvements are for their entire audience.”
Because accessibility isn’t separate from user experience — it is user experience.
Many of the requirements outlined in the EU Accessibility Act overlap directly with what makes software intuitive and usable for everyone. When you improve accessibility, you’re also making your product:
- Easier to navigate — especially for users on mobile, older users, or anyone dealing with temporary impairments (like a broken trackpad or noisy environment)
- Faster to understand — thanks to clearer labels, content structure, and predictable interaction patterns
- More trustworthy — users notice when a product “just works,” no matter how they access it
This pays off in very measurable ways:
- Higher conversions: Fewer blockers = more completed checkouts and signups
- Lower churn: Frustrated users don’t stick around — inclusive UX keeps more people engaged
- Better SEO: Search engines rely on accessible HTML (headings, alt text, semantic structure) to understand and rank your content
- Stronger legal position: Accessibility complaints are on the rise — and now, they come with EU enforcement behind them
Chris can confirm that these outcomes aren’t just wishful thinking or assumptions — they happen all the time:
“We have compared the before/after on traffic and conversions on websites where accessibility is being improved. On average, we see traffic increases by 15% and conversions surge 2-3% within 30-60 days, when fixing accessibility alone.
I want to emphasize this: Those numbers come from only resolving accessibility issues, no other major changes. The list of things you can do that get those kinds of results is very, very short.“
So why now?
Because the deadline has already passed, and fixing accessibility after the fact is costlier than fixing it up front. If you haven’t started, you’re not early anymore, you’re catching up. You’ll be forced to rewrite components, patch together compliance, and risk damaging your product’s reputation in the meantime. Starting now gives you a chance to:
- Build accessibility into your design system, not bolt it on after launch
- Prevent future rework
- Stay ahead of legal and market expectations
- Serve a broader user base from day one
Even small steps make a difference. Fixing heading structure, adding alt text, or checking color contrast can instantly improve usability.
Because the EAA isn’t just about compliance. It’s about reaching more users, reducing friction, and building products that work better for more people.
That’s the kind of software people come back to.
What this means for Freemius users
If Freemius is already part of your stack, some of your EAA exposure is already handled. Your Checkout and Customer Portal, the two places your EU customers interact with your business most directly, are fully audited, updated, and WCAG 2.1 AA compliant, and neither requires you to write a line of code.
“We started by reviewing the law and identifying the key areas where our sellers interact with end-users — primarily the Checkout and the Customer Portal,” says Swashata Ghosh, VP of Engineering at Freemius.
Here’s the current status:
- Checkout: Fully audited, updated, and WCAG 2.1 AA compliant
- Customer Portal: Tested, tweaked, and up to WCAG 2.1 AA spec
These updates were prioritized ahead of the June 2025 enforcement deadline, so Freemius-powered stores could keep selling in the EU without interruption. That work has held up since.
“We pushed hard to get the Customer Portal updates completed by the end of the month. Accessibility is a must-have, not an afterthought.”
For you, that means a manual screen reader audit (VoiceOver, NVDA, JAWS), full keyboard navigation across the entire checkout flow with no focus traps, and ARIA live regions so screen readers catch pricing and validation changes as they happen, all already done.
The JS SDK picked up matching updates: the close button is now always visible instead of hover-only, the modal and iframe carry proper role and title attributes, and focus returns correctly when the modal closes.
On Customer Portal, it means your customers get improved keyboard navigation, stronger screen reader support, clearer focus states, and compliant color ratios, alongside a soft visual refresh that didn’t touch any custom CSS overrides you already had in place.
For more info on the enhancements we implemented, read our EU Accessibility Act release notes.
Quick start: How to get started
You don’t need to overhaul your entire product to start improving accessibility. With EU Accessibility Act enforcement already underway, what matters most is progress, not perfection.
Here’s how to take meaningful action, even if you’re a solo developer or small team with limited time.
1. Run an accessibility audit
Before you start fixing things, figure out what actually needs fixing. A good audit surfaces technical issues and usability barriers that might be invisible to you, but critical for your users.
Recommended tools:
- Equalize Digital’s Accessibility Checker – especially useful for WordPress products
- axe DevTools – works inside your browser’s dev tools for instant feedback
- WAVE – browser-based tool that gives clear visual indicators on what’s wrong
These tools can highlight common problems like missing alt text, low color contrast, or inaccessible forms.
Marco Almeida, founder of Webdados and Naked Cat Plugins, even built a plugin that can help make websites accessible when they need to insert multi-language content on the page.
“I was already using Lang Attribute for the Block Editor before this functionality was merged into core, but it only allows you to set the language at a text level, like formatting,” explains Marco.
“For one of my projects, I need to be able to set the language at a group block level, so all the contents inside are considered to be in that language. This is crucial for accessibility — assistive reading technologies, like screen readers. My initial motivation was, as in most cases, the fact that I had a use for it, but the fact that the new EU rules related to accessibility were around the corner was just an extra push.”
Amber was here to support a fellow software maker.
“I still haven’t got feedback from others on actually using the plugin, but Amber helped me validate that the “lang” and “dir” attributes can be used at a higher level (like the group block) and will affect everything inside. I’m planning to ask other accessibility experts for feedback as well,” Marco adds.
Chris enjoys seeing the impact of his and his wife’s work with WordPress product makers, who have been coming to them for help with accessibility:
“For instance, our team had the privilege of working with Woo to address all accessibility issues in their core plugin, which now largely conforms with WCAG. Those improvements and the work we did together have made it so that millions of eCommerce sites globally are inherently more accessible with the latest versions of Woo.”
2. Tackle low-effort, high-impact fixes
Start with the stuff that gives you the biggest return for the least effort:
- Add alt text to all images and icons — it should describe the function or content, not just say “image”
- Use proper heading hierarchy (H1 > H2 > H3) — don’t skip or misuse headings for visual purposes
- Fix color contrast — use a contrast checker to make sure text is readable against its background
- Ensure keyboard navigation — users should be able to tab through links, buttons, and forms
- Label your form fields properly — use HTML <label> tags and make sure they’re associated correctly
Each of these improves both usability and compliance, and none of them requires a full redesign.
3. Know when to bring in an expert
If your product is complex or you’re unsure how deep the issues go, it’s worth consulting an accessibility specialist.
Look for someone who has experience with:
- Digital accessibility audits for SaaS or plugin-based platforms
- Interpreting and applying WCAG 2.1 AA
- Prioritizing improvements based on actual user impact
Because, ultimately, your users are what truly matters.
“I’ve spoken to dozens of individuals who build WordPress themes and plugins,” says Chris, “and they’re all saying the same thing: Customers are starting to ask for proof that their solutions meet accessibility standards. And that is what I think is driving the mindset shift toward accessibility more than anything.”
As Chris explains, “the EAA as a piece of regulatory guidance was actually released several years ago. June 28 is a deadline that everyone in the accessibility world has known about for years, and now that the deadline has come, an ever-increasing number of software makers started to take it seriously.”
Working with an expert to make sure your website or software is compliant doesn’t only mean you’re taking EAA seriously — it can also save you time, reduce legal risk, and help you focus your efforts where they matter most.
4. Level up your understanding
Accessibility isn’t just a checklist — it’s a mindset. Invest a bit of time now to avoid bigger problems later. And truly take time to understand what it means to make your software available to individuals with disabilities.
“Testing tools, audits, standards, and operating procedures are the beginning and end of some people’s exposure to accessibility (at least professionally),” Chris comments.
“But I have worked side by side with some incredible people, including individuals with disabilities. I have heard their stories and it’s hard to quantify in a short and snappy answer how important these best practices are for humanity, for all of us.”
Chris continues: “In the real world, accessibility can be the difference between getting a safe ride home and having to walk miles on unfamiliar streets. Accessibility can be the difference between being able to buy food, or clothing, or accessing information, and having to rely on the charity of others to complete basic tasks online.”
“Accessibility can be the difference between someone contributing to their full potential in society, and being locked out of opportunities that most of our peers get to have by default.”
Great places to learn:
- WebAIM WCAG 2.1 Checklist – easy-to-follow breakdown of requirements
- Deque University – includes free and paid courses, especially good for devs
- The A11Y Project – community-driven resource full of how-tos and examples
- Equalize Digital’s blog and videos – accessibility insights and expert advice
5. Publish your accessibility statement and support channel
If you’re providing a covered service, you need to publish an accessibility statement.
A simple link in your website footer is usually enough to make it easy to find. Your statement should explain what standards you’re measuring against, what’s already accessible, what isn’t yet, and how to report a problem.
You should also provide an accessible way for users to contact you about accessibility issues, such as an accessible support form, email address, or help channel.
The exact requirements can vary by EU country, but the goal is straightforward: users should be able to understand your service’s accessibility and easily report problems.
For most software businesses, creating the statement and support channel is a relatively small task compared with fixing accessibility issues in the product itself.
Bottom line? You can’t afford to ignore this.
The best time to build accessibly was when you started. The second-best time is right now. You don’t need to fix everything overnight — just commit to improving one thing at a time.
For example, here’s what you can start with:
“Our CTO, Steve Jones, has said over and over again that developers need to learn semantic HTML deeply, and make sure their code is outputting correctly,” says Chris.
“This is one of the best things a developer can do to make sure what they build is compatible with assistive technology. To start: Make sure your links are coded as links, your buttons are coded as buttons, and that your form fields are properly labeled.”
That’s the first step to making sure your product helps more people do what they came to do. And that’s not just compliance. It’s good software.
Stay compliant and gain a competitive advantage
The EU Accessibility Act is pushing the industry forward, but it’s up to us as software makers to meet the moment. Ignoring accessibility now means risking legal action, alienating users, and falling behind products that are easier for everyone to use.
But this doesn’t have to be about fear or red tape. It’s a chance to build better software — cleaner, more inclusive, more resilient. Start with small changes. Fix what you can. Learn as you go.
Take it from our experts: “Digital accessibility isn’t a fad or a trend. It is getting a lot of attention right now because of major pieces of legislation in the EU and elsewhere, but these best practices are as old as the internet itself,” says Chris.
“As the internet has gotten increasingly complex, we’ve “forgotten” the importance of making sure what we build can be used by everyone. I would encourage readers to educate themselves, seek help and guidance, and invest in solutions that help them measure and manage accessibility effectively.” — Chris Hinds
Use this momentum not just to comply, but to create something more usable, more thoughtful, and more valuable for every user who touches it.
Frequently asked questions about EU Accessibility Act
Does the EU Accessibility Act apply if my company isn’t based in the EU?
Yes. If your business sells covered products or services to customers in the EU, the EAA can apply even if your company is based outside the EU.
Are WordPress plugins and themes covered by the EAA?
No, not simply because they’re WordPress plugins or themes. The EAA doesn’t list WordPress plugins or themes as a product category. What matters is whether the product or services covered by the EAA include the one you’re providing.
What’s the difference between the EAA and the EU Web Accessibility Directive?
They’re two different EU laws. The EU Web Accessibility Directive only applies to public-sector websites and apps, like government portals. The EAA is the one that applies to private businesses, including software makers, SaaS companies, and online stores selling to EU consumers.
What’s the difference between the EAA and WCAG 2.1 AA?
The EAA is a law; WCAG 2.1 AA is an accessibility standard. The EAA tells covered businesses what they legally need to achieve. WCAG provides technical criteria for making websites and digital products accessible.
Do I need to redesign my product to comply with the EAA?
No, you don’t need to redesign your entire product. You need to fix the accessibility barriers that prevent the parts covered by the EAA from meeting its requirements.
Does the microenterprise exemption cover my business?
Only if you’re a qualifying microenterprise providing services. A microenterprise is generally a business with fewer than 10 employees and annual turnover or balance-sheet total of no more than €2 million. The exemption applies to qualifying service providers, not manufacturers of covered products.
Can I claim an exemption if compliance is too expensive for my business?
In narrow cases, yes. Article 14 of the EAA lets you claim a “disproportionate burden” exemption for a specific requirement if the cost of meeting it clearly outweighs the benefit to users with disabilities. It isn’t a blanket pass: you have to document the assessment, keep it on file for five years, and reassess it at least that often. It also only excuses that one requirement, not your product as a whole.
What happens if my product isn’t EAA compliant?
You can be required to fix it, withdraw it from the market, or stop making it available. EU Member State authorities enforce the EAA and can impose penalties under their national laws.
Is Freemius Checkout EAA and WCAG 2.1 AA compliant?
Freemius Checkout and Customer Portal are designed with accessibility in mind, but that doesn’t make your entire website or product EAA-compliant. Checkout and Customer Portal are only one part of the customer experience. Your own website, product, and other customer-facing interfaces still need to meet the European Accessibility Act requirements that apply to them.
Is WCAG mandatory in the USA?
No. WCAG itself isn’t mandatory under US law. It’s a technical accessibility standard. US laws such as the ADA can create accessibility obligations, while specific regulations may use WCAG as their technical standard.
