Magento and Adobe Commerce accessibility: a platform-specific guide

Magento and Adobe Commerce power a significant share of mid-market and enterprise ecommerce stores, particularly in B2B, manufacturing and specialty retail. The platform's complexity, its multiple active theme architectures and its heavy use of JavaScript view models create specific accessibility challenges that differ substantially from what you encounter on Shopify or WooCommerce.

This guide covers the accessibility failures that appear in real Magento and Adobe Commerce audits: the Luma theme, the Hyva theme ecosystem, PWA Studio, layered navigation, configurable products, the checkout steps and Knockout.js accessibility patterns.

The Magento theme landscape and its accessibility implications

Magento's long history means stores run on several distinct theme architectures, each with different accessibility profiles. Understanding which architecture you are on determines what fixes are possible and how complex they are.

Luma is the default frontend theme included with Magento 2 and Adobe Commerce. It is built on RequireJS, LESS and Knockout.js. Most Magento stores using traditional (non-PWA) frontends are either running Luma directly or a custom theme based on it.

Hyva is a third-party theme framework launched in 2021 that has rapidly become the leading alternative to Luma. It replaces RequireJS and Knockout with Alpine.js and Tailwind CSS. Hyva stores tend to have better performance and a cleaner codebase than Luma, but accessibility is not a guaranteed improvement.

PWA Studio (Venia) is Adobe's React-based progressive web app framework. It is used by a minority of merchants but is favored in high-traffic enterprise deployments.

Luma theme accessibility: the baseline problems

The Luma theme has never prioritized accessibility. A fresh Luma installation fails dozens of WCAG 2.1 AA criteria. These are the most consequential.

Navigation menu keyboard accessibility

Luma's main navigation is a multi-level dropdown menu. The top-level menu items are anchor elements. Hovering reveals a dropdown submenu. The keyboard behavior is broken:

• Submenus open on hover but not on keyboard focus. A keyboard user tabbing through the navigation never sees the submenu items.
• The submenu items, while present in the DOM, cannot be reached by keyboard because the submenus are CSS display-toggled based on hover state only.
• There is no aria-expanded attribute on top-level navigation items to indicate whether a submenu exists or is open.
• Arrow key navigation between navigation items is not implemented. WCAG recommends the disclosure navigation pattern (Enter or Space to open a submenu, arrow keys to navigate within it, Escape to close).

This is a WCAG 2.1.1 failure, one of the most common issues in keyboard navigation testing. Fixing it requires replacing or significantly modifying Luma's navigation JavaScript. The fix is not trivial: it requires implementing a proper disclosure navigation pattern with keyboard event handling.

Form labels and placeholders

Several Luma form implementations use placeholder text as the only visible label for inputs. This fails WCAG 1.3.1 and 1.1.1. The login form, the search field and the newsletter signup all have this problem in the default Luma configuration. Placeholder text disappears when a user starts typing, leaving them with no indication of what the field expects.

Focus visibility

Luma's default CSS removes focus outlines on many interactive elements. The rule outline: none appears in multiple LESS files. This is a WCAG 2.4.7 failure (Focus Visible). Every interactive element must have a visible focus indicator. Removing all outlines for aesthetic reasons is a compliance violation.

Layered navigation accessibility

Magento's layered navigation (faceted filtering on category pages) is one of its most-used features and one of its worst accessibility implementations.

Filter panel structure

Each filter attribute (Size, Color, Price, Brand) is a section with a heading and a list of filter options. In Luma, these sections use a custom collapse/expand pattern with JavaScript toggling. The toggle buttons do not use <button> elements in older versions and consistently lack aria-expanded to communicate their state.

Filter options (individual values like "Blue", "M", "$50-$100") are rendered as anchor links rather than checkboxes. This creates several problems:

• The selected state of a filter option is communicated only by visual styling (a checkmark icon). There is no aria-checked or similar attribute to communicate the selected state programmatically.
• Multiple-select filter behavior (selecting multiple values in the same attribute group) is possible through the UI but the semantic model does not communicate that these are checkboxes. Screen reader users hear "link: Blue" not "checkbox: Blue, checked".
• After a filter is applied and the page updates (full page reload in Luma, AJAX in many customizations), focus position is not managed. Focus drops to the top of the page.

AJAX filtering focus management

Many Magento implementations replace Luma's full-page-reload filtering with AJAX filtering (using extensions like Amasty Improved Layered Navigation or Smile ElasticSuite). When the product grid refreshes via AJAX, screen reader users need to know that the results have changed. This requires a live region announcement: the new product count should be announced, and focus should move to the product grid or the result count heading.

Configurable products on Magento

Magento's configurable product type (the Magento equivalent of WooCommerce variable products) has accessibility issues in both the Luma implementation and many custom implementations.

Swatch configuration

Magento's built-in swatches extension (Magento_Swatches) renders color and size options as <div> elements styled as swatches. The default implementation:

• Uses <div> instead of <input type="radio"> or <button> elements, making swatches completely keyboard inaccessible by default.
• Does not use a <fieldset> and <legend> to group the options by attribute name.
• Communicates selected state only through CSS classes, not through ARIA attributes.

The fix involves modifying Magento_Swatches/templates/product/view/renderer.phtml to use role="radio" and tabindex on swatch elements, wrapping them in a role="radiogroup" container with an accessible name, and implementing keyboard event handling for arrow key navigation between options.

Out-of-stock configuration

When a variant combination is out of stock, Magento applies a CSS class to show the swatch as unavailable. The unavailability is not communicated programmatically. Add aria-disabled="true" and a title attribute or visually hidden text like "(unavailable)" to out-of-stock swatches.

Magento checkout step accessibility

Magento's checkout is a two-step process: Shipping and Review & Payments. It is a JavaScript-heavy single-page application built with Knockout.js.

Step transitions and focus management

When a user completes the Shipping step and the checkout transitions to the Payment step, focus is not moved to the new step content. In the default Luma checkout, focus stays wherever it was in the Shipping step, now pointing at DOM elements that may have been removed or hidden. Screen reader users must navigate the entire page to find the payment form.

The fix: after the step transition animation completes, move focus programmatically to the Payment step heading. In Luma's checkout JavaScript (Magento_Checkout/js/view/), hook into the step change event and call focus() on the target heading element.

Address form fields

The Magento checkout shipping address form is one of the better-implemented parts of the Luma checkout. Form fields have associated labels. Required fields have programmatic indication via asterisks. Error messages are injected adjacent to fields.

The remaining issues:

• Required field error messages are injected into the DOM but not associated with their field using aria-describedby. Screen readers announce the error when focus moves to the error message, but do not announce it when focus is on the field.
• The country and state dropdowns are native <select> elements and keyboard accessible. But the state dropdown update (which loads new options when the country changes) is not announced via a live region.
• Shipping method radio buttons are correctly implemented as a radio group in newer versions of Luma. Older versions used anchor elements that were not keyboard accessible.

Knockout.js accessibility concerns

Knockout.js is Magento's view model library. It manages DOM updates reactively based on observable data. This architecture creates specific accessibility risks.

When Knockout updates the DOM in response to data changes (product price updating after variant selection, cart total updating, checkout step rendering), those updates are not announced to screen readers by default. The standard fix is to identify which DOM updates represent status changes to users and add ARIA live regions to the elements Knockout is updating.

The price element in a configurable product template should have aria-live="polite". The cart summary in checkout should have a live region wrapping the total. The error message containers should use role="alert" (which is equivalent to aria-live="assertive").

Hyva theme accessibility

Hyva replaces Luma's JavaScript stack with Alpine.js and x-data directives. This makes it significantly easier to implement ARIA patterns correctly compared to Luma's RequireJS and Knockout complexity.

What Hyva gets right

Alpine.js's x-bind directive makes it straightforward to bind ARIA attributes to reactive data. For example, a dropdown menu can use :aria-expanded="open" to automatically update the aria-expanded attribute as the Alpine data property changes. This is cleaner than Luma's approach.

The Hyva base theme also includes a better focus management foundation and several components that have been built with accessibility in mind (the mobile menu, modal overlay, toast notifications).

What Hyva does not guarantee

Hyva itself is a frontend framework. Individual Hyva components (from Hyva-Themes, the Hyva marketplace or custom development) vary in their accessibility quality. A Hyva store can be highly accessible or highly inaccessible depending on the components used and how they are implemented.

Common Hyva accessibility failures in the wild: color swatch components without proper radiogroup semantics, mega menus without keyboard arrow navigation, product carousels without keyboard and screen reader support, AJAX filter updates without live region announcements. Use our accessibility testing tools to catch these issues early in development.

PWA Studio (Venia) accessibility

Adobe's PWA Studio uses React. The Venia storefront component library has received accessibility improvements in recent versions. React's nature makes it easier to write accessible components (proper focus management, ARIA via JSX) but also makes it easy to introduce SPAs-specific failures (client-side routing without focus management, dynamic content without live regions).

For PWA Studio stores, the most common accessibility failures are:

• Route changes not announcing the new page title to screen readers. Native browser navigation announces page titles; client-side routing does not unless you implement a page announcement mechanism.
• Cart and wish list operations updating React state without corresponding live region announcements.
• Third-party React components used for product galleries, carousels and custom inputs that were not built with accessibility in mind.

Third-party extension accessibility

The Magento/Adobe Commerce marketplace has thousands of extensions. Accessibility testing is not part of the Marketplace review process. Extensions that inject content into product pages, category pages or checkout are responsible for a significant share of total accessibility violations on Magento stores.

The highest-risk extension categories: product review widgets (same problems as on other platforms), live chat integrations, loyalty program widgets injected into checkout, size guide modals, age verification gates and cookie consent banners. If you are migrating between platforms, our replatforming compliance checklist covers what to audit before and after the switch.

Adobe Commerce Cloud considerations

Adobe Commerce Cloud (the hosted managed service, formerly Magento Commerce Cloud) does not change the frontend accessibility profile. The underlying Magento frontend is the same. However, Adobe Commerce Cloud customers typically have enterprise-scale implementations with extensive customizations and many third-party integrations, meaning more surface area for accessibility failures.

Adobe has published a VPAT for Adobe Commerce. The VPAT documents known non-conformances in the admin interface (the Magento admin panel used by merchants and developers, not the customer-facing storefront). The customer-facing storefront accessibility depends entirely on the theme and customizations used.

How to prioritize Magento accessibility work

Given Magento's complexity, prioritization is critical. Start with:

• Checkout form labels and step focus management. These directly block purchase completion for keyboard and screen reader users.
• Navigation keyboard accessibility. If keyboard users cannot navigate to categories, they cannot reach products.
• Configurable product swatch keyboard access. Required to add products with variants to the cart.
• Focus outlines. Restore focus visibility across the entire store. This is a CSS change that can be deployed quickly.
• Layered navigation semantics. Important for category pages but lower risk than checkout.

Frequently asked questions

Is Magento accessible by default?

Magento's Luma theme has significant accessibility gaps including unlabeled form fields, poor focus management and heading hierarchy issues. The newer Hyva theme offers better performance but also requires accessibility work.

What are the biggest Magento accessibility issues?

The most common issues are unlabeled checkout form fields, missing ARIA attributes on dropdown navigation, poor keyboard navigation in layered navigation filters and inaccessible third-party extension output.

Does Magento's PCI scope affect accessibility compliance?

Magento self-hosted installations have the largest PCI scope in ecommerce, but PCI and accessibility are separate compliance domains. However, both require attention on checkout pages, making a combined audit more efficient.