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.