Magento 2 accessibility under the European Accessibility Act

Part 6 of the Storefront Conversion Engineering series — accessibility is law now, not a nice-to-have.

Why this matters

The European Accessibility Act (EAA) turned WCAG 2.2 AA from a best practice into a market-access requirement for e-commerce serving EU customers. Enforcement dates have arrived, and the exposure is concrete: orders placed through inaccessible checkout flows, penalties from national authorities, and private claims that cost more in legal time than the remediation would have. For Magento merchants selling into the EU, an inaccessible storefront is now a blocked storefront.

Default themes are not compliant out of the box. Luma carries years of known gaps: low-contrast grey text on product listings, keyboard traps in the mini-cart and layered navigation, form fields without persistent visible labels, and checkout error messages that appear visually but are never announced to assistive technology. Hyva starts from a cleaner Tailwind and Alpine base and fixes whole classes of Luma problems, but a stock Hyva theme still ships with merchant-introduced gaps the moment CMS content, third-party extensions, and custom checkout modules enter the picture. Compliance is a property of the built store, not of the starter theme.

The business case runs alongside the legal one. Accessible checkout converts better for everyone: clearer labels reduce form abandonment, visible focus reduces lost-keyboard-user drop-off, and properly associated errors reduce repeat submission failures. Remediation framed as conversion work gets funded. Remediation framed as paperwork gets deferred until a complaint arrives.

How it works

A remediation plan that survives contact with a real backlog has three passes: audit, prioritized fix, and gating. Each pass is concrete.

Audit with automation plus keyboard walkthroughs

Start with automated scans (axe-core, Lighthouse accessibility, or WAVE) across home, category, product, cart, checkout, account, and search results. Automation catches roughly a third of WCAG failures: missing alternative text, duplicate IDs, empty links, form inputs without labels, insufficient contrast ratios flagged programmatically. It does not catch meaning: whether focus order matches visual order, whether a modal traps and releases focus correctly, whether an error message is announced.

So pair every automated run with a manual keyboard walkthrough of the purchase path: tab from header to footer on each template, complete a purchase using keyboard only, and repeat the checkout with a screen reader (NVDA or VoiceOver) at least once per release. Record the walkthrough as a checklist in the repo so regressions are reviewable. The templates that matter most are product configuration (swatches, custom options), cart quantity controls, and the full checkout sequence including shipping method selection, payment method selection, and order placement.

Fix in WCAG 2.2 AA priority order

Work through the checklist items that block transactions first:

• Contrast (1.4.3, 1.4.11). Body text needs 4.5:1 against its background; large text 3:1; UI components and focus indicators 3:1. The usual Magento offenders are grey price prefixes, placeholder-as-label patterns, sale badges, and swatch selected states. Fix tokens in the theme variables file so the correction propagates instead of being patched per template.
• Keyboard operability and focus visibility (2.1.1, 2.4.7, 2.4.3). Every action reachable by mouse must be reachable by keyboard, focus must be visible on every interactive element, and focus order must be meaningful. Mini-cart dropdowns, layered navigation filters, mega menus, and date pickers are the repeat offenders. Never remove focus outlines without supplying a stronger replacement.
• Labels, names, and error association (3.3.1, 3.3.2, 4.1.2, 4.1.3). Every input needs a persistent visible label plus a programmatically associated name. Checkout errors need aria-describedby pointing at the message and, on submit, focus moved to the error summary with role="alert" or an equivalent live region. Placeholder attributes are not labels. Title attributes are not labels.
• Target size minimum (2.5.8, WCAG 2.2 AA new). Pointer targets need at least 24 by 24 CSS pixels of spacing-adjusted size. Product quantity steppers, cart remove icons, swatch buttons, and mobile filter chips routinely fail this. Enlarge the hit area with padding rather than shrinking the visual design.
• Consistent navigation and headings (2.4.6, 1.3.1). One h1 per page reflecting the product or category, heading levels that nest without skipping, landmarks (header, nav, main, footer) intact, and skip-to-content links present and working. Screen reader users navigate by headings; a flat or skipped hierarchy strands them.
• Redundant entry and accessible authentication (3.3.7, 3.3.8, WCAG 2.2 AA new). Do not force shoppers to re-enter information already provided in the same session, and do not require solving puzzles or transcribing codes without an accessible alternative. Checkout address reuse and password managers must work unimpeded.

Decorative issues (redundant title attributes, suboptimal heading phrasing on CMS pages) go to the bottom of the queue. Transaction blockers go first, always.

Gate deployments on accessibility checks

Add axe-core checks to the CI pipeline alongside visual regression: fail the build on critical and serious violations on the audited templates, track the count as a metric, and require the keyboard walkthrough checklist for any pull request touching checkout, navigation, or form markup. Keep an accessibility statement page current (it is itself an EAA expectation) documenting conformance status, known limitations, and a contact path for assistance. An honest statement with a remediation timeline is stronger than a boilerplate claim of full compliance that testing disproves.

Pitfalls

• Overlays marketed as compliance without fixing the underlying markup. Accessibility widgets that inject a toolbar leave the DOM semantics broken: unlabeled inputs stay unlabeled, focus order stays wrong, screen readers still miss errors. Regulators and courts look at the underlying page, not the overlay badge. Fix markup; skip the overlay.
• Checkout errors announced to nobody using a screen reader. The standard Magento failure mode is a red border plus text injected without a live region or focus move. Sighted testers see it; screen reader users submit again and fail again. Every checkout error path needs an announced message and a focus target. Test it with a screen reader, not just by reading the template.
• Touch targets below minimum on product and cart actions. Designers handed a 16-pixel remove icon consider the job done. Fingers disagree, and WCAG 2.2 AA now sets the floor at 24 by 24. Pad hit areas on steppers, swatches, chips, and icon buttons as a theme-level rule.
• Fixing contrast in one place while CMS content reintroduces it. Merchants pick light-grey body text in the page builder the week after engineering fixes the theme tokens. Constrain the CMS palette to passing combinations and document which token pairs are approved. Otherwise the audit passes on deploy day and fails by month end.
• Treating Hyva as automatically compliant. Hyva removes Luma-era structural debt, but extensions, payment modules, and custom Alpine components reintroduce every classic failure. Run the same audit and gating on Hyva builds. Cleaner starting point, same discipline required.

Closing

EAA compliance for a Magento store is a finite, sequenced project: audit the purchase path with automation plus keyboard and screen reader passes, fix transaction blockers in WCAG 2.2 AA priority order (contrast, keyboard and focus, labels and error association, target size), and gate deploys so the gaps stay closed. Done this way, the work compounds: fewer abandoned checkouts, fewer support escalations, and a conformance position the business can document instead of hope for.

Next in this series:

magento2-consent-mode-gdpr-tracking