Magento Accessibility Compliance: The EAA, WCAG & ADA Guide

Since 28 June 2025, the European Accessibility Act (EAA) has made digital accessibility a legal requirement across the EU. If your website, app, or store isn't accessible to people with disabilities, you can face fines, takedown orders, or being blocked from the EU market - even if your business is based elsewhere.

No more ignoring keyboard-only navigation, weak contrast, or missing image descriptions. You need to meet recognized standards like WCAG 2.1 AA (Web Content Accessibility Guidelines) and show evidence of compliance. The Act opens access to over 100 million people in the EU with disabilities - and stores that stay inaccessible are already losing their share of that market.

You'll learn what EAA compliance means for a Magento 2 store, how to test yours, and where our modules already cover you.

Table of Contents

• EAA compliance: what it means for your E-commerce store
• How to meet the standard in your Magento 2 store
• How to make your Magento 2 store accessible
• How Mirasvit modules handle accessibility

EAA compliance: what it means for your E-commerce store

If you run a Magento store and sell to EU customers, EAA compliance is mandatory. It doesn't matter where your business is based. What matters is where your buyers are.

This means your website, checkout flow, mobile app, and customer support tools all need to meet digital accessibility requirements. If they don't, you risk fines, takedown orders, or being blocked from one of the world's largest markets.

Does the EAA apply to your store?

Most e-commerce businesses selling to the EU are covered. The main carve-out is for microenterprises - broadly, fewer than 10 employees and under €2 million in annual turnover - and it's narrower for products than for services (see the exemption breakdown). If you're a growing Magento merchant selling across the EU, assume you're in scope.

EAA (EU) and ADA (US): one checklist for both

The EAA isn't the only accessibility law with teeth. In the US, the ADA is enforced through a steady stream of lawsuits, and both regimes point at the same technical target: WCAG 2.1 AA. Meet that once and a single checklist serves your EU and US customers alike.

What enforcement looks like now

Enforcement is no longer hypothetical. In France, an early EAA court ruling against Carrefour rejected a defense of 71% partial conformance, ordered full accessibility within six months, and set a €500/day penalty for delay. Formal notices have gone out to major French retailers, and in Germany merchants have started receiving Abmahnungen (formal warnings) under unfair-competition law since August 2025. The pattern is clear: regulators and competitors are both acting on the deadline.

How to meet the standard in your Magento 2 store

The European Accessibility Act doesn't introduce new technical standards - it enforces existing ones. For websites and e-commerce platforms, that means following WCAG 2.1 compliance guidelines and the legally binding EN 301 549 standard.

If you run a Magento 2 store, these are the baseline requirements for digital accessibility compliance, and you may be asked to document them in a web accessibility audit.

WCAG 2.1 AA compliance: key requirements for EAA

WCAG (Web Content Accessibility Guidelines) defines how to build websites and online stores that are usable for people with visual, auditory, motor, or cognitive disabilities. Level AA compliance is the standard required by law under the EAA.

In practice, it means:

These principles support both e-commerce accessibility and an inclusive user experience for all users, not just those with disabilities.

WCAG 2.1 AA is the current legal baseline. Keep an eye on WCAG 2.2 AA, though: it's expected to fold into EN 301 549 (v4.1.1) around late 2026, once it's referenced in the EU's Official Journal. Testing against 2.2 now saves you a rework later.

EN 301 549: how the standard affects your Magento 2 store

EN 301 549 connects the WCAG 2.1 rules to legally enforceable obligations across the EU. It's what ties the code in your theme to your legal responsibility.

The key takeaway is this: meeting the standard isn't just about design - it's about documentation.

You may be asked to provide web accessibility audit logs, detail what tools you used, and show proof of fixes - test reports, developer notes, and a consistent review process. One artifact is now effectively mandatory: a published accessibility statement that declares your conformance status, lists known barriers, and gives visitors a feedback channel to report problems.

If you're working with developers or agencies, make sure accessibility tools for developers, like automated scanners and manual testing protocols, are part of the build and QA workflow. Inclusive user experience shouldn't be a last-minute patch. It needs to be part of your development process from the start.

How to make your Magento 2 store accessible

Not sure if your Magento store meets EAA compliance requirements? We've prepared a practical accessibility checklist, based on WCAG 2.1 AA and the EN 301 549 standard, that covers the essential items you'll need to pass a basic audit.

Here's the full checklist:

1. Automated vs manual testing

Start with an automated checker like Axe, WAVE, or Lighthouse. These tools flag obvious issues like missing alt text or low contrast. But don't stop there - automated tools can't tell whether your link text makes sense or your layout is logical, so manual checks are essential.

2. Keyboard-only navigation

Unplug your mouse and try browsing with only the Tab, Enter, and Arrow keys. Can you reach every menu, product, filter, and form field? If your store traps users, skips key elements, or hides dropdowns on a tab, it's not accessible.

3. Screen reader compatibility

Use a screen reader like NVDA (free for Windows) or VoiceOver (built into Mac) and navigate your store from the top. Listen for confusing labels, missing hierarchy, or redundant content, and make sure important information is read out clearly and in the right order.

4. Text contrast and scalable content

Check that text has enough contrast against its background (4.5:1 for normal text) and that the layout stays usable when you zoom to 200%. Nothing should overlap, get cut off, or disappear.

5. Alt text and descriptive links

Every meaningful image needs alternative text, and links should describe where they lead - not "click here". Decorative images should be marked so screen readers skip them.

6. Forms, labels, and error messages

Every field needs a visible, programmatically associated label. Errors must be announced clearly and explain how to fix the problem, not just flag that something is wrong.

7. ARIA roles and semantic structure

Use native HTML elements where you can, and ARIA roles only where you must. Headings should follow a logical order, and interactive components (menus, sliders, modals) need the right roles and states.

8. Mobile accessibility

Repeat the keyboard, contrast, and screen-reader checks on mobile. Tap targets should be large enough, and content shouldn't rely on hover or precise gestures.

9. Nothing on color or motion alone

Don't use color as the only way to convey meaning (like a red field for an error), and give users a way to pause or stop any automatic motion.

📥 Download the same checklist as a PDF if you'd rather work from a printable version with your QA team.

Overlay widgets don't make you compliant

A quick note, because it comes up a lot: accessibility overlay widgets - the plugins that promise "instant compliance" from one line of JavaScript - don't make your store EAA compliant. The European Commission's position is that they don't satisfy the requirements, and in the US the FTC fined overlay vendor accessiBe $1 million over misleading claims. There's no shortcut here - the fixes have to live in your actual markup and templates.

Accessibility can also regress as you add content, products, or extensions, so it's worth watching a live site over time rather than testing once and forgetting. A few monitoring services crawl a running site on a schedule (weekly, monthly, or whenever content changes) and alert you when a new issue appears:

• axe Monitor (Deque) - runs on-demand or scheduled scans against WCAG, Section 508, and EN 301 549, and is built to track issues across large sites over time.
• Pope Tech - built on WebAIM's WAVE engine; schedule weekly, monthly, or quarterly crawls and get the report in your inbox.
• Siteimprove - enterprise-grade, site-wide monitoring that also covers PDFs and tracks an accessibility score across your whole domain.

These don't replace manual testing - the same limits apply as any automated tool - but they catch the obvious regressions before a customer or a regulator does.

How Mirasvit modules handle accessibility

We built our Magento 2 modules with accessibility in mind, and we check them against the key requirements of the European Accessibility Act.

How we test our extensions

Every module with a storefront (frontend) component goes through the check. Admin-only modules are out of scope - they render inside Magento's admin theme, which shoppers never see, so their accessibility isn't something a single extension controls.

The check has two levels:

• Automated scan - We run Lighthouse (Google's built-in accessibility auditor) in our CI pipeline before every release. It doesn't catch everything - no scanner does - but it reliably flags the things that clearly fail the requirements: missing labels, broken focus order, weak contrast.
• Manual review - When a module fails the scan, it goes back to the developer for a detailed pass by hand: navigating with only a keyboard, checking contrast, and testing with a screen reader. Each finding ends one of two ways - we fix it, or we document it as a false positive (scanners produce those too).

One caveat worth stating plainly: we test against Magento's standard theme. If your store runs a heavily customized theme, that theme can introduce its own accessibility issues and needs to be checked separately - our testing covers our code, not your storefront's theme.

You don't need to tweak code or change settings to make it work. Just install the module and use it as documented - it's ready.

Accessibility questions? We've got answers

If something in your store looks off and you're not sure if it's caused by a module, you can ask. We'll help you check:

• Does this element respond to screen readers?
• Can users get through it without a mouse?
• Is the contrast strong enough?

These questions are part of normal support. You don't need a special plan or contract - we're here to help you understand how our modules behave.

We can't audit your whole store, but we can make sure our part holds up.