Neither Magento Open Source nor Adobe Commerce makes a shop accessible or inaccessible on its own. What counts is the storefront your customers get, and on Magento that can be one of three very different things: a theme built on Luma or Blank, a Hyvä theme, or a headless frontend. This page separates what Adobe and the frontend vendors give you from what stays your job – in most mid-market shops, your agency's – and names the places to test first.
Does the BFSG apply to your Magento shop?
If you sell to consumers through Magento or Adobe Commerce, you provide an e-commerce service – in the words of the law, a "Dienstleistung im elektronischen Geschäftsverkehr" (§ 1(3) no. 5 BFSG). In Germany the Barrierefreiheitsstärkungsgesetz has applied to such services since 28 June 2025. It transposes the European Accessibility Act, so shops selling into other EU countries meet equivalent national laws there [1][2].
Micro-enterprises that provide services are exempt: fewer than 10 employees and an annual turnover or balance sheet total of no more than €2 million (§ 2 no. 17, § 3(3) BFSG) [1]. Details are on our page on the micro-enterprise exemption. A purely B2B shop that only sells to business customers is not a service to consumers. Many Magento installations serve trade and consumers from one codebase; if consumers can buy, treat that side as covered.
Scope, market surveillance and the information you have to publish are explained in BFSG for online shops. Comparing platforms? See Shopware and OXID eShop.
What the platform gives you, and what it does not
You get:
- Two reference themes and inheritance. Magento ships Luma as a demonstration theme and Blank as the basis for custom themes. A custom theme can inherit from either and override only the files it changes [4]. A fix in the parent reaches every child – and so does a defect.
- A published conformance report. Adobe has published an Accessibility Conformance Report for Adobe Commerce (May 2021), evaluated against WCAG 2.0 and 2.1 at levels A and AA and EN 301 549 V3.1.1, and it covers the Luma storefront [3].
- Newer frontends with an accessibility claim. Hyvä states that its theme implements accessibility features according to WCAG 2.1 level AA from release 1.3.0 [6]. Adobe's own storefront on Edge Delivery Services, built from drop-in components [7], lists accessibility fixes in its release notes, most recently in July 2026 [8].
- Slider settings in Page Builder. Page Builder (Adobe Commerce since 2.3.1, Magento Open Source since 2.4.3) [10] lets editors switch autoplay, arrows and dots on or off per slider [11].
You do not get:
- A conformant Luma. Adobe's report rates the Luma storefront "Partially Supports" on, among others, non-text content, info and relationships, keyboard, focus order, focus visible, labels and name, role, value [3].
- Accessible extensions. Every extension with frontend output brings its own templates and JavaScript. Hyvä's documentation says it plainly: care is needed not to degrade accessibility, both with installed extensions and with theme changes [6].
- A finished headless frontend. Adobe calls Venia, the PWA Studio storefront, "a proof-of-concept storefront" [9]. What your agency built on it is its own code.
- Useful alt text. Alt text comes from your catalogue data – the product image settings, an import or a PIM – and no theme claim covers it.
What we find on Magento shops
Themes that inherit Luma's defects
Many mid-market shops run a custom theme that inherits from Luma or Blank. Whatever the parent does wrong, the child keeps unless somebody overrides that template. Adobe's own report lists such defects in Luma: primary navigation items that cannot be activated with a keyboard, pagination controls on list pages without a visible focus indicator, and a main gallery image that is interactive but has no suitable role [3]. Check whether your theme ever fixed them.
Layered navigation and swatches
Sidebar filters reload the product list without announcing the number of results, and focus often jumps to the top or disappears. Configurable products set up with visual or text swatches show the selected option only as a border, and an unavailable combination only as a greyed-out tile. When price or stock changes after a selection, a screen reader hears nothing.
Mini-cart and messages that nobody hears
After "Add to basket", a message appears at the top and a counter changes in the header; neither is announced. The mini-cart drop-down opens without moving focus into it, and its close button is often an icon without a name.
Headless frontends and client-side routing
PWA and headless builds change pages without a page load. Unless the frontend handles it, the title stays the same, focus stays on the clicked link, and a screen-reader user is not told a new page has loaded. The fixes in Adobe's July 2026 storefront release – accessible names, status announcements, autocomplete attributes, reflow of the header panels [8] – show which kind of defects occur.
Checkout, CAPTCHA and extensions
The standard checkout is built from JavaScript UI components [5]; many shops replace it with a one-step checkout extension. For the Luma checkout, Adobe's report names the discount code field receiving focus after the "Place Order" button, a heading structure that does not reflect the content, required fields marked only with an asterisk in some forms, and a CAPTCHA in sign-in and checkout that relies on an image without an alternative challenge [3].
Page Builder content
A Page Builder slider can start on page load and repeat indefinitely, with a default delay of 4,000 milliseconds between slides [11]. Without a visible pause control, that fails WCAG 2.2.2. Banners with the headline baked into the image bypass everything the theme does right.
Where to look first
| Criterion | Why on Magento | Automation |
|---|---|---|
| 2.1.1 Keyboard (A) | Luma navigation, swatches, extension menus | Partly automated |
| 2.4.3 Focus Order (A) | Discount code after "Place Order", mini-cart, client-side routing | Partly automated |
| 2.4.7 Focus Visible (AA) | Pagination, theme CSS | Partly automated |
| 4.1.2 Name, Role, Value (A) | Gallery image, swatches, icon buttons | Partly automated |
| 4.1.3 Status Messages (AA) | Add-to-basket message, filter results | Manual only |
| 3.3.2 Labels or Instructions (A) | Required fields marked only with an asterisk | Partly automated |
| 3.3.8 Accessible Authentication (Minimum) (AA) | Image CAPTCHA at sign-in and checkout | Manual only |
| 1.1.1 Non-text Content (A) | CAPTCHA image, catalogue images | Partly automated |
| 2.2.2 Pause, Stop, Hide (A) | Autoplaying Page Builder sliders | Partly automated |
| 1.4.3 Contrast (Minimum) (AA) | Theme colours, sale badges | Automated |
"Automated" means a rule can decide the criterion on its own; "partly automated" means a rule finds some failures and a person has to judge the rest. The full list is in WCAG 2.2 AA, criterion by criterion.
A sensible order of work
- Name your frontend and its owner. Luma child theme, Hyvä or headless – and which version. That decides whose code a finding is in and who fixes it.
- Diff against the parent. Scan a staging copy with the plain parent theme (Blank, Luma or the Hyvä default) or your headless boilerplate. Whatever disappears came from your theme.
- Walk the purchase journey with a keyboard, in every store view that sells to consumers. Category → layered navigation → configurable product → basket → checkout → payment in sandbox mode.
- Inventory extensions with frontend output. Checkout, search, menus, reviews, consent. Patch, replace or document each as a known limitation, and ask vendors for test evidence rather than a badge.
- Fix catalogue data at the source. Alt text and swatch labels belong in the admin, the import or the PIM, not in templates.
- Re-test after every upgrade. Releases, Hyvä updates and new drop-ins change markup; make an accessibility check part of the agency's acceptance criteria.
What Reviseberg checks on Magento – and what you still test yourself
Reviseberg crawls your shop, including category and product pages, and runs every axe-core rule on every page at a desktop width of 1280 pixels, then repeats the rules that change with the layout – contrast and target size among them – at 360 pixels. Results are mapped to WCAG 2.2 A/AA and EN 301 549. Findings are grouped into issues by rule and ranked by the points you gain by fixing them, so a defect in a parent template shows up as one issue on 400 pages rather than 400 separate entries. From an account, Reviseberg can also crawl a staging site behind a password.
The keyboard agent opens the pages of a journey you name – a category page, a product page, the basket – and presses Tab, Shift+Tab and Escape through each of them, recording every step. It reports unreachable elements, lost or invisible focus, missing skip links and keyboard traps. It does not fill in forms or place an order, so the checkout steps behind a full basket and the payment iframe are yours to walk by hand. The free report covers up to 100 pages and runs the keyboard agent on one page you choose.
You still test some things yourself: whether alt text actually describes the image, whether error messages make sense, and how the shop behaves with a screen reader and zoom. Screen-reader, zoom and voice-control agents are not built yet; for those criteria the platform gives you guided manual tests, and a criterion nobody has tested is reported as untested, never as passed. There is no Magento extension and no connector: nothing is applied to your shop automatically, and we never inject an overlay script.
Written to be useful, not as legal advice. As of 27 September 2026.