Platform Guides

Magento / Adobe Commerce Accessibility for Mid-Market Stores

Last updated May 24, 2026

Magento, now formally Adobe Commerce, is the platform behind tens of thousands of mid-market and enterprise storefronts. It is also the platform with the worst measured accessibility baseline of any major ecommerce engine. Three things drive that result. The default Luma frontend is a decade-old stack built on KnockoutJS and RequireJS, and the patterns it ships are not the patterns a 2026 audit expects. Adobe Commerce stores are usually heavily customized, which means your codebase is closer to a bespoke application than to a managed theme. And the marketplace extensions you bolt on top — sliders, reviews, layered-nav add-ons, configurators — vary wildly in quality and frequently inject markup that bypasses whatever a11y discipline your theme has.

The good news for store owners: most of the violations driving that 85.4 number are mechanical. Missing form labels, low-contrast badges, icon-only buttons without accessible names, and broken focus order are not architectural problems — they are diff-sized fixes in your theme's web/css and layout XML. This guide is for the developer or store owner who wants to move from “worst on the leaderboard” to audit-ready without re-platforming. It covers Luma, Hyvä, the checkout flow, layered navigation, and the marketplace-extension layer that quietly regresses every release.

Why Magento scores poorly on automated audits

The Luma frontend, which still powers the majority of live Adobe Commerce storefronts, predates the modern web component model. Templates are composed via layout XML, behavior is wired up through KnockoutJS bindings, and dependency loading runs through RequireJS. That stack works, but it forces patterns that audit tools flag by default: dynamic regions updated without aria-live, form fields whose labels are emitted by a different template than the input, and JavaScript-rendered controls that never receive a rendered type or accessible name until after first paint.

Three things compound the platform baseline. First, most mid-market stores run a customized Luma child theme, often by an agency that shipped the build five years ago and has not touched it since. Second, the marketplace ecosystem encourages installing extensions for everything from product reviews to one-page checkout — every extension is a new author with their own a11y opinions, or none. Third, Adobe's own accessibility documentation in the Adobe Commerce knowledge base is honest but light — it documents that the platform does not guarantee WCAG conformance out of the box and that conformance is the merchant's responsibility.

Luma theme — known issues

Luma is the reference frontend shipped with Adobe Commerce. If you have not switched to Hyvä, you are almost certainly running a Luma child theme. The same handful of failures appear on nearly every Luma audit we have seen:

• Sale badge and label contrast. The default sale badge and “new” badge sit close to 3:1 against the product-card background — below the 4.5:1 normal text threshold. See our color contrast guide for the math.
• Link focus indicators below 3:1. Luma's default link underline-on-focus is subtle and often disabled by child themes that override the global focus rule. WCAG 2.4.11 requires a focus indicator with at least 3:1 contrast against adjacent colors.
• Multi-step checkout transitions. The step indicator updates visually when the user moves from Shipping to Review to Payment, but the transition is not announced. Screen-reader users hear nothing change.
• Search auto-suggest dropdown. The auto-suggest list lacks role="listbox" wiring on the input, and option-count updates are not announced to assistive tech.
• Mini-cart fragment updates. Adding to cart updates the mini-cart counter and items list via a Knockout binding. The region updates silently — no aria-live on the count, no announcement of the new item.
• Layered-nav filter groups. Filters render as flat lists of checkboxes or links per attribute; the attribute group itself rarely has a fieldset + legend, so screen-reader users hear an unlabelled list of options.

Hyvä theme — what it improves

Hyvä is the most popular third-party frontend for Adobe Commerce, built on Tailwind CSS and Alpine.js. It replaces the Knockout and RequireJS layer entirely with a thinner, modern stack. The accessibility wins are real: Hyvä ships better semantic HTML by default, the off-canvas mini-cart uses a documented Alpine pattern with proper focus management, the search and layered-nav components are rewritten with explicit ARIA wiring, and the form-label coverage in checkout is materially better. WebAIM Million 2025 did not publish a Hyvä-versus-Luma split, but the field reports from agencies that have rebuilt on Hyvä — and our own scan data on Hyvä installations — consistently land below the platform average, rather than at 85.4.

That said, Hyvä is not a free pass. The theme is a starting point, not a finished product. Every Hyvä installation is customized per store, and most integrators do not run a post-customization accessibility audit. The most common regressions we see on Hyvä builds are custom product configurators that lose keyboard support, off-canvas overlays added by the merchant that re-introduce focus leaks, and Tailwind utility chains that drift below contrast thresholds because nobody re-tested the palette after a brand refresh. The platform gives you a better baseline; the audit discipline is still yours.

Checkout accessibility — the highest-stakes flow

Checkout is where accessibility failures translate directly to lost revenue and to demand-letter exposure. The Luma multi-step checkout (Shipping → Review → Payment) has a recurring set of violations that nearly every audit flags:

• Step transitions not announced. The step indicator updates visually, but the live-region update never fires.
• Address auto-fill from saved addresses silently overwrites form values without notifying assistive tech.
• Payment-method radio group missing fieldset + legend wrapping, so the group is announced as a sequence of unrelated radios.
• Stripe, Braintree, or PayPal iframes are inserted into the page without surrounding context — the iframe has no title and the parent region is unnamed.
• The “Place Order” button toggles to a disabled state during validation without a visible or programmatic reason.
• The order-success page renders without managing focus, so screen-reader users do not hear the confirmation.

Two of these are pure CSS and one-liner JS fixes. First, restore a high-contrast focus indicator on every interactive element in checkout — drop this into your theme's <your_theme>/web/css/source/_extend.less (Luma) or your Tailwind layer (Hyvä):

/* WCAG 2.4.11 — 3:1 minimum focus indicator on every focusable element. */
.checkout-index-index :where(
  a, button, input, select, textarea, [tabindex]:not([tabindex="-1"])
):focus-visible {
  outline: 2px solid #0a4e9b;          /* contrasts against white + grey */
  outline-offset: 2px;
  box-shadow: 0 0 0 4px rgba(10, 78, 155, 0.25);
}

Second, announce the checkout step transition. The Luma step indicator already renders a data-role="step-content" wrapper for each step; attach a live-region message when the active step changes:

// Drop into a RequireJS module loaded from your checkout layout XML.
define(['jquery'], function ($) {
  'use strict';
  // Inject a polite live region once.
  var $live = $('<div role="status" aria-live="polite" class="visually-hidden"></div>')
    .appendTo('body');

  // Observe the step indicator: Luma toggles the .active class on each step.
  var observer = new MutationObserver(function () {
    var label = $('#checkout-step-title.active, .opc-progress-bar-item._active')
      .first().text().trim();
    if (label) $live.text('Now on ' + label + ' step.');
  });
  observer.observe(document.querySelector('.opc-progress-bar') || document.body, {
    subtree: true, attributes: true, attributeFilter: ['class'],
  });
});

The rest of the checkout fixes — payment-iframe titles, fieldset/legend on the payment radio group, focus management on the success page — are template overrides. They are tedious, not difficult, and they are what separate an 85.4-error baseline from a checkout that actually closes for keyboard and screen-reader users.

Layered navigation and filters (PLP)

Layered navigation — the “shop by” sidebar on category pages — is one of Magento's defining features and one of its most consistently inaccessible patterns. The recurring failures:

• Filter buttons rendered icon-only (filter funnel, close X) without an aria-label or visually hidden text.
• Price-range sliders driven by a JavaScript-only handle, with no keyboard alternative input and no programmatic value updates.
• “In stock” or “On sale” toggles rendered as a list of checkboxes without a group label, so screen-reader users hear unlabelled options.
• “Clear all filters” activated without confirmation or an undo affordance, often with no announcement that the result set changed.
• Result-count updates after a filter change rendered into the page but never announced. The catalog quietly refreshes underneath an unaware user.

Wrap each attribute group in a fieldset with a visible legend, add a polite live region next to the result counter, and provide a number-input fallback for the price slider. For the off-canvas filter panel on mobile, follow the same focus-management contract covered in our accessible modals guide.

Marketplace extensions — the wildcard

You can ship a clean Luma child theme and still fail an audit because of the eight marketplace extensions sitting on top of it. A product-image zoom plugin re-renders the gallery without preserving alt text. A reviews plugin paints star ratings as coloured spans with no text alternative. A configurator overlays its own modal with a broken focus trap. The pattern is the same every time: an extension injects markup that bypasses whatever discipline your theme has, and your audit picks up the result.

The defensible workflow is to vet accessibility before purchase. Ask the vendor for an accessibility statement or a current axe-core report. Run the extension's demo store through a scanner. If you cannot get either, treat the extension as untested and budget for a manual audit after installation. Any extension that injects a modal, a slider, a tooltip, a fly-out menu, or a custom form control is high-risk by default — pick extensions whose authors can point to a recent third-party audit, or audit them yourself.

Practical Magento audit checklist

A realistic mid-market audit pass, in order:

1. Run an automated scan on the rendered storefront — home, a PLP, a PDP, the cart, every checkout step, and the order-success page. Use a crawler that waits for KnockoutJS or Alpine to hydrate, not a static fetch.
2. Fix the mechanical issues first: missing alt text, missing form labels, low-contrast badges and CTAs, icon-only buttons without accessible names, and the focus-indicator restore in checkout.
3. Wrap layered-nav attribute groups in fieldset + legend; provide keyboard alternatives for any slider control.
4. Add aria-live announcements on three places: mini-cart update, layered-nav result-count update, and checkout step transition.
5. Title every payment iframe; name the parent region; manage focus on the order-success page.
6. Manually keyboard-test every modal and off-canvas overlay the store renders — extensions included.
7. Run a screen-reader pass on the checkout end-to-end. Automation cannot tell you whether the announcer you wired up actually fires.
8. Re-scan and diff. The remaining issues are the ones that need a design decision or an extension swap.

Per Deque's Automated Accessibility Coverage Report, Deque reported automated tests identified 57.38% of issue instances by volume in its dataset — based on 2,000+ audits across 13,000+ pages and ~300K issues (a dataset-specific volume measure, not a clean automated-vs-manual split). That means an automated scan, by itself, will never get you to a defensible posture. It will get you out of the bottom of the leaderboard; judgment-dependent items still require the manual pass above. Our WCAG 2.2 checklist covers what to look for during that manual review.

Code-level fixes you can apply

A few patterns that recur in nearly every Luma remediation. First, a layout XML override to add a missing landmark label — Magento renders the main content region without an accessible name on several page types:

<?xml version="1.0"?>
<page xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:noNamespaceSchemaLocation="urn:magento:framework:View/Layout/etc/page_configuration.xsd">
  <body>
    <referenceContainer name="main.content">
      <arguments>
        <argument name="attributes" xsi:type="array">
          <item name="role" xsi:type="string">main</item>
          <item name="aria-label" xsi:type="string">Product catalog</item>
        </argument>
      </arguments>
    </referenceContainer>
  </body>
</page>

Second, a KnockoutJS template override that adds a live-region announcement when the mini-cart updates. Drop into <your_theme>/Magento_Checkout/web/template/minicart/content.html:

<div role="status" aria-live="polite" class="visually-hidden"
     data-bind="text: getCartParam('summary_count') + ' items in cart'">
</div>
<!-- existing mini-cart markup follows -->

Third, an accessible-name fix for the search auto-suggest combobox. The default search input does not announce itself as a combobox or surface the suggestion count — wire the ARIA combobox pattern in your theme's Magento_Search/templates/form.mini.phtml override and reference the visible label.

How SweepHound supports Magento

SweepHound's crawler waits for the full rendered storefront — KnockoutJS bindings on Luma, Alpine hydration on Hyvä — before scanning, so it catches the dynamic markup that static fetchers miss. The dual-engine pass runs axe-core alongside IBM Equal Access on every page, which is meaningful on Magento specifically because the two engines disagree most often on the patterns Luma uses: combobox wiring, live-region updates, and aria-labelledby relationships across separate templates. Where one engine has a blind spot, the other often catches the issue.

Remediation is deterministic-first. For mechanical fixes — missing alt text, missing labels, contrast failures, icon-only buttons — you get before/after code instead of a generic explanation. For Magento-specific patterns the engine recognizes the layout XML and KnockoutJS template structure and emits guidance in the form your developers already work in. And for authenticated-page testing — the customer account area, saved-address flows, wishlists, and order history — Growth and Agency plans support credentialled scanning so the logged-in surfaces get the same coverage as the public storefront.

For broader context on ecommerce accessibility, see our ecommerce accessibility playbook and the sibling WooCommerce guide. If a demand letter has already arrived, our response guide walks through what to do next, and our overlay analysis explains why a one-line widget is not a fix.

Ready to see where your Adobe Commerce store actually stands? Start a free SweepHound scan — you get a dual-engine baseline and deterministic remediation on your first crawl. Authenticated scanning, scheduled re-scans, and published accessibility statements are on Growth and Agency; see pricing for details. Or if you already know which subscription tier you want, head straight to sign-up and we will have a Magento-aware scan running in under five minutes.