By platform · Magento and Adobe Commerce
Big Catalogs, Custom Storefronts, Real Stakes
Magento stores are large, heavily customized, and usually run by companies whose contracts now name a standard. The scope of an audit here follows your templates, not your URLs.
Last reviewed August 30, 2026
For the e-commerce or engineering lead on a Magento or Adobe Commerce store with a compliance requirement attached.
Magento sits at the enterprise end of e-commerce, and that changes the picture in two ways. Storefronts here are almost always custom, so nothing about a default theme predicts what yours does. And accessibility arrives through contracts rather than through complaints. Procurement gets here before anybody's customer does.
The second point decides how to approach it. You are likely to be asked for evidence, and what a buyer means by evidence is a rule-by-rule result with a pass or a fail against each one, usually written up as a VPAT or an accessibility conformance report. A scanner score answers a different question, and no procurement team has ever accepted one in place of the answer.
One thing is worth knowing before you start. Of every platform we write guides for, this is the only one whose vendor publishes no first-party accessibility guidance for theme developers at all. That absence is part of why storefronts on this platform vary as widely as they do.
What breaks on Magento and Adobe Commerce
The failures we find most often on this platform, and the rule each one breaks.
Layered navigation filters
Faceted filters update the product grid asynchronously and announce nothing, so a screen reader user has no way to know the page changed under them or how many results are left.
4.1.3 Status Messages
Configurable product swatches
Size and color swatches render as list items with click handlers attached, which exposes no name, no role and no selected state. Visually it is obvious which one is chosen. Programmatically it is nothing.
4.1.2 Name, Role, Value
Multi-step checkout
Magento's checkout is a JavaScript application, and step changes frequently move nothing. Focus stays where it was, no progress is announced, and a keyboard user has to hunt for where the page went.
2.4.3 Focus Order
Mini-cart and message areas
Success and error messages render into regions that are not live, so the message appears on screen and reaches nobody who is not looking at that part of it.
4.1.3 Status Messages
Whichever storefront you actually run
Luma and Hyvä behave differently, and a headless storefront is a separate codebase again with its own accessibility profile. Each one needs its own testing, and results from one tell you nothing about another.
1.3.1 Info and Relationships
Product image galleries
Fotorama is still the default gallery through the current release line, and the galleries that replace it are frequently mouse-only with lightboxes that hold focus. The keyboard behavior here is our finding rather than anything Adobe documents.
2.1.2 No Keyboard Trap
The plugin question, answered
Magento's extension marketplace carries fewer accessibility extensions than WordPress or Shopify, and a good share of what is there is an overlay widget. We have not counted the category, so read that as an impression rather than a number.
At this scale, an extension bolted onto production is not the practical route anyway. Testing built into how your team ships is, because a store this size regresses faster than anybody can retest it by hand.
Automated checks in your pipeline
An accessibility rules engine running against your key templates as part of every build.
- What it does
- It catches regressions on every commit, across a codebase far too large to retest by hand. This is the place automation genuinely earns its keep, because the same check runs a thousand times and never gets bored.
- What it cannot
- It covers the machine-checkable rules only. Our own technique-by-technique count puts that at 10 of the 356 WCAG techniques and failures we graded, which is 2.8%, with 228 visible to a scanner only in part. Twenty-four of the 55 Level A and AA criteria have no conformance-tested automated rule behind them at all.
Storefront frameworks that output semantic markup
Building on a frontend framework whose components produce real elements by default.
- What it does
- Prevention beats remediation, and across several hundred templates it is not close.
- What it cannot
- It will not fix the templates already in production, and a framework marketed on accessibility is making a vendor claim rather than reporting a test result. Ask what was tested and by whom before you treat it as a head start.
Overlay widgets (accessiBe, UserWay, AudioEye and the rest)
A script you paste into your template that draws a toolbar for visitors and claims to repair your pages automatically as they load.
- What it does
- The toolbar half is real. Bigger text, higher contrast, adjusted spacing and a reading guide are preferences some visitors use, and the field's own reference document on overlays says a non-trivial array of accessibility problems can genuinely be repaired this way.
- What it cannot
- It does not change the markup your server sends, and the categories it handles worst are the ones that decide whether a site works at all. Text alternatives, form labels and error handling, and keyboard access. More than 5,000 US digital accessibility lawsuits were filed in 2025, and the firm that compiles that dataset reads the filings the same way every year, which is that widgets do not materially reduce legal risk. Our overlays page has the documented record.
What to actually do
- List your distinct templates rather than your URLs. Home, category, product, configurable product, cart, each checkout step, account. That list is your real scope, and it is usually shorter than people fear.
- Then multiply it by the breakpoints that change the DOM, because every responsive variation of a page has to work on its own for the page to conform.
- Test the full purchase flow by keyboard and with a screen reader, including a payment that fails, because the failure path is the one nobody has walked.
- Check that layered navigation announces the result count when a filter changes, and that swatches expose which option is selected.
- Add automated accessibility checks to your build for the mechanical rules, so the same regression cannot ship twice.
- Get a rule-by-rule audit if a contract or a buyer is asking for evidence, because a scanner score will not satisfy either of them.
On themes and templates
Hyvä-based storefronts generally produce cleaner, lighter markup than Luma, which helps and is not the same as conforming. Hyvä markets accessibility as a feature, and that is a vendor claim rather than an independent finding, so treat it as a reason to expect less work rather than a reason to skip the testing. Headless storefronts built on React or Vue have their own accessibility profile entirely, and our React and Vue audits cover those.
One honest limit
Magento stores are too large to audit by sampling URLs, so we scope this work by template, times the breakpoints that change the markup. For a store with a big catalog and several checkout variants that is a bigger engagement than our flat-rate audit, and we would rather say so here than halfway through. Talk to us about scope rather than assuming the standard offer fits.
Keep reading
Other platforms
Magento
We test all 55 WCAG 2.2 A and AA rules on your Magento and Adobe Commerce site, with an expert review and a real blind screen-reader user on your key journeys. Every finding screenshotted and mapped to its fix. $499, report in 5 business days.