AccessScanRun a free scan

Guide

Magento Accessibility: A Practical Guide for Adobe Commerce Stores

Magento accessibility is now a commercial requirement, not a nice-to-have. Since 28 June 2025, the European Accessibility Act (Directive (EU) 2019/882) has applied to e-commerce sold to EU consumers, and the technical baseline it expects is WCAG 2.2 Level A and AA, referenced through the EN 301 549 standard.

The challenge with Adobe Commerce is that a single store stitches together theme templates, Knockout.js components, third-party extensions, and merchant-uploaded content. A barrier can live in any of those layers. This guide walks through the four areas where Magento stores most often fail an audit, plus what the EAA means for EU sales, with concrete fixes you can hand to a developer.

Theme markup: the Luma and Hyvä foundation

Most Magento accessibility problems start in the theme. The legacy Luma theme ships markup that predates WCAG 2.2, and even custom Hyvä builds introduce issues when developers swap semantic elements for styled <div> tags. Three structural problems recur across stores.

  • Missing landmarks and heading order: every page needs one <main>, a <nav> for the primary menu, and a logical h1-h2-h3 sequence. The product name should be the page h1, not a styled span.
  • Icon-only buttons with no name: Luma's mini-cart toggle, search icon, and wishlist heart often render as empty <button> elements. Add an aria-label (for example, aria-label="Open cart, 3 items") so screen reader users know what they activate.
  • Skipped focus styling: themes frequently set outline: none on :focus to hide the default ring. Replace it with a visible :focus-visible style. WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum, AA), so a sticky header that hides the focused element is now a failure; 2.4.13 Focus Appearance sets a stricter ring standard at Level AAA.

Test the foundation by unplugging your mouse and tabbing through a category page. Every interactive element should take focus in a sensible order with a visible ring, and the broader principles map to the four WCAG pillars: perceivable, operable, understandable, robust.

Product images and alt text

Catalog images are where merchant content meets code. Magento auto-generates an alt attribute from the image label field on the product, and if that field is blank the storefront emits alt="" or repeats the file name. A screen reader then announces "IMG_4471 dot jpg" instead of "Navy merino wool crew-neck sweater."

  • Populate the Alt Text field on each product image in the admin, not just the product name. Describe what the shopper would see: material, color, and key feature.
  • For zoom and gallery widgets (Fotorama in Luma), make sure thumbnail buttons have accessible names and that the gallery is operable by keyboard, not drag-only. WCAG 2.5.7 Dragging Movements (AA) requires a single-pointer alternative.
  • Mark purely decorative images (background swooshes, spacer graphics) with alt="" so assistive tech skips them.

Writing good descriptions at catalog scale is its own skill: name the product type, material, color, and the one detail a shopper buys on, and skip phrases like "image of."

Faceted (layered) navigation

Layered navigation is the most interaction-heavy part of a Magento store and the most commonly broken. Filters for size, color, and price are usually rendered as plain links or custom widgets that keyboard and screen reader users cannot operate predictably.

  • Color swatches must be real buttons or checkboxes with a text label, not bare <span> elements colored with CSS. A swatch that conveys meaning by color alone also fails the 3:1 contrast expectation for UI components under WCAG 1.4.11.
  • When a filter is applied and the product grid updates over AJAX, announce the change. Add an aria-live="polite" region that reports "24 products found" so non-sighted users know the list refreshed without a full page reload.
  • Expose the state of each filter group with aria-expanded on the toggle, and keep the active-filter chips reachable and removable by keyboard.
  • Meet 2.5.8 Target Size (Minimum, AA): interactive filter targets should be at least 24 by 24 CSS pixels, which matters on the mobile facet drawer where swatches are often cramped.

Checkout: the highest-stakes flow

Magento's one-page checkout is built on Knockout.js and renders fields dynamically. That dynamism is exactly where accessibility breaks, and a broken checkout means lost revenue from every shopper using assistive technology.

  • Every input needs a programmatically associated <label>. Magento sometimes relies on placeholder text alone, which disappears on input and is not a label. Pair this with autocomplete attributes (autocomplete="email", "postal-code") so browsers can fill fields, supporting WCAG 1.3.5.
  • Surface validation errors in text, tied to the field with aria-describedby, and move focus to the first error. Color-only error states fail 1.4.1 Use of Color.
  • Honor 3.3.7 Redundant Entry (A): if a shopper entered a shipping address, do not force them to retype it for billing. Magento's "same as shipping" checkbox should be the default and keyboard-reachable.
  • For login and guest checkout, 3.3.8 Accessible Authentication (Minimum, AA) means do not require a cognitive test such as a puzzle CAPTCHA with no accessible alternative.

Because checkout fields are generated client-side, manual testing matters. Our accessible forms guide details the label, error, and focus patterns that survive a Knockout re-render.

EAA implications for EU e-commerce

If you sell to consumers in the EU, the European Accessibility Act applies to your store regardless of where your company is based. Enforcement is handled by national market-surveillance authorities, and penalties vary by member state, so treat conformance as ongoing rather than a one-time project. Microenterprises (broadly, fewer than 10 staff and under a set turnover) may fall outside parts of the scope, but most growing Adobe Commerce merchants will not.

The practical baseline is WCAG 2.2 A and AA via EN 301 549. Two operational steps follow: keep evidence of testing, and publish an accessibility statement describing your conformance and a contact route for feedback. You can draft one with our accessibility statement generator, and our European Accessibility Act overview explains who is in scope and how the rules connect to WCAG.

A fast way to triage your own theme is to run a free check against your live storefront. Scan a page with AccessScan to surface missing alt text, contrast failures, and unlabeled controls, then prioritize the category, product, and checkout templates.

Check your site against AccessScan

See your issues ranked by impact in seconds — free.

Run a free accessibility scan

FAQ

Does the EAA apply to my Magento store if I'm based outside the EU?

Yes. The European Accessibility Act applies to products and services offered to consumers in the EU, regardless of where the seller is established. If EU shoppers can buy from your Adobe Commerce store, the WCAG 2.2 A and AA baseline applies from 28 June 2025.

Is the Hyvä theme more accessible than Luma out of the box?

Hyvä's lean markup makes it easier to build an accessible store, but it does not guarantee conformance. Accessibility depends on how your developer implements labels, focus styles, ARIA, and contrast. Both themes need testing and remediation against WCAG 2.2.

Will an accessibility widget or overlay make my store compliant?

No. Overlays do not reliably fix theme markup, faceted navigation, or checkout issues, and they cannot substitute for conformant code. Fix the underlying templates and components, then verify with manual keyboard and screen reader testing plus an automated scan.

What's the single highest-impact area to fix first?

Checkout. A barrier there directly blocks purchases. Prioritize labeled form fields, text-based validation errors with focus management, and accessible authentication, then move to faceted navigation and product images.

More guides