EAA compliance for Magento (Adobe Commerce): WCAG 2.1 AA checklist & fixes

What the EAA actually requires from a Magento (Adobe Commerce) site

Magento (Adobe Commerce) stores almost never run the stock Luma theme in production, so under the EAA the obligation attaches to your heavily customised child theme or a PWA Studio (Venia) headless storefront. EN 301 549 conformance forces you to fix configurable-product swatches implemented as clickable spans that keyboard users cannot select, and one-step-checkout extensions that replace the default flow with a tighter UI that loses label associations. Because these are large, extension-laden platforms, the requirement really means auditing the production theme and every commerce extension, not the vanilla download.

Magento is a mid-market and enterprise platform, frequently powering high-revenue B2C and B2B commerce, which puts these operators at the sharp end of EAA penalties where turnover-percentage regimes like France's up-to-4% become a material financial threat. B2B Magento deployments also sit in the EAA's later-transition B2B services scope, and the sheer transaction volume means an enforced fix-or-suspend order carries a very large opportunity cost. For this user profile the fine math is driven by revenue scale, so accessibility neglect is a genuine board-level financial risk rather than a nuisance.

Remediation requires a Magento development team working in the production theme's templates and Less/CSS, or in the React codebase for a PWA Studio storefront, rather than any point-and-click editor. The disciplined approach is to disable extensions like one-step checkout to isolate whether a failure is core or extension-introduced, fix swatch keyboard support and checkout labels, and integrate axe-core into the Magento Functional Testing Framework. Given the codebase size and release process, this is a planned multi-sprint engineering effort with regression testing built in.

Top WCAG failures we see on Magento (Adobe Commerce) sites

Across hundreds of Magento (Adobe Commerce) scans, the same handful of issues show up over and over. None of them require ripping the theme apart — most are fixable in a few hours by someone comfortable in the platform's editor or template files.

• Configurable product swatches without keyboard support

  Color/size swatches commonly use clickable spans; keyboard users cannot select variants.

  2.1.1, 4.1.2 — Level A

• One-step-checkout extensions stripping field labels

  Third-party checkout modules often replace the default with a tighter UI that loses label associations.

  1.3.1 — Level A

Concrete code fixes for Magento (Adobe Commerce)

Below are copy-paste fixes for the most common Magento (Adobe Commerce) issues. They assume you have access to your theme code or the platform's custom-code injection panel. If you cannot edit code directly, share these snippets with whoever maintains the site — every one of them is a ten-minute change.

// Disable any one-step-checkout module before auditing the default checkout flow.
// Re-enable and re-test to compare.

Tools and plugins worth installing first

• Magento Functional Testing Framework with axe-core integration

• PWA Studio Venia template (more modern, generally more accessible than Luma forks)

How to scan a Magento (Adobe Commerce) site without missing anything

Automated scanners catch about 30–40% of WCAG issues; the rest need manual review. The good news is that the 30–40% includes the most expensive issues to remediate after the fact, so an automated scan is the cheapest way to get unstuck. Run one before you change a line of theme code.

• Crawl PDP, PLP, /checkout/cart, /checkout, and /customer/account/login.