Shopware Accessibility Checklist 2026 | WCAG 2.1 AA & EAA

In the Shopping Experiences editor, text and 'image + text' blocks let merchants style large headline text without marking it as a heading, and category/landing pages are often assembled with no H1 or with heading levels chosen for size rather than hierarchy. Screen reader users who navigate by headings find no outline, or one that jumps levels, and cannot scan the page.

<div class="cms-element-text">
  <p style="font-size:2.5rem;font-weight:700">Summer Collection</p>
</div>

<div class="cms-element-text">
  <h1 style="font-size:2.5rem;font-weight:700">Summer Collection</h1>
</div>

The Shopware product configurator renders variant properties (size, colour, material) as selectable swatches or buttons. When these are styled <div>/<span> or buttons whose only label is a colour swatch, screen reader users cannot tell what property they are setting or read the selected value - 'button' with no name, repeated across a row.

<div class="product-detail-configurator-options">
  <span class="swatch" style="background:#c00"></span>
  <span class="swatch" style="background:#00c"></span>
</div>

<div role="radiogroup" aria-label="Colour">
  <button role="radio" aria-checked="true" aria-label="Red">
    <span class="swatch" style="background:#c00"></span></button>
  <button role="radio" aria-checked="false" aria-label="Blue">
    <span class="swatch" style="background:#00c"></span></button>
</div>

Adding a product slides in Shopware's off-canvas cart, and the mobile menu opens the same off-canvas pattern. In customised themes these overlays frequently open without moving focus into themselves, leave focus on the page behind them, cannot be closed with Escape, and do not return focus to the trigger on close - trapping keyboard and screen reader users behind the panel.

<div class="offcanvas">
  <!-- slides in; focus stays on the page behind -->
  <div class="cart-items">...</div>
</div>

<div class="offcanvas" role="dialog" aria-modal="true"
     aria-label="Shopping cart">
  <button class="offcanvas-close" aria-label="Close cart">x</button>
  <div class="cart-items">...</div>
</div>
<!-- JS: focus the panel on open, Escape closes, focus returns -->

Shopware shows toast-style notifications for actions like adding to cart, applying a voucher, or newsletter sign-up, and Flow Builder can trigger on-page messages. When these are rendered as visually-styled toasts without an ARIA live region, screen reader users get no confirmation that the action succeeded or failed.

<div class="alert alert-success show">
  Product has been added to the shopping cart.
</div>

<div class="flashbags" role="status" aria-live="polite"></div>
<script>
  document.querySelector('.flashbags').textContent =
    'Product has been added to the shopping cart.';
</script>

The product gallery slider (and Shopping Experiences image-slider element) often ships next/previous controls that are icon-only buttons with no accessible name, autoplay that cannot be paused, and slide images with empty or duplicated alt text. Screen reader users hear 'button' with no function and miss the product views entirely.

<button class="gallery-prev"><i class="icon-arrow-left"></i></button>
<img src="v2.jpg" alt="">

<button class="gallery-prev" aria-label="Previous image">
  <i class="icon-arrow-left" aria-hidden="true"></i>
</button>
<img src="v2.jpg" alt="Leather bag, interior pocket detail">

Shopware's theme manager makes it easy to set a brand primary colour for buttons, links, and badges, and merchants frequently choose a light or low-contrast brand colour that fails the 4.5:1 ratio for button text and sale/special prices. Low-vision shoppers then struggle to read the 'Add to cart' and 'Checkout' actions.

$sw-color-buy-button: #7fb3ff; /* white text fails */
.product-price--special { color:#ff7a7a; } /* fails on white */

$sw-color-buy-button: #1f5fc2; /* white text passes */
.product-price--special { color:#c0392b; } /* passes on white */

Custom Shopping Experiences form blocks and some theme overrides render newsletter and registration inputs with placeholder-only prompts or labels that are visually hidden in a way that also removes them from the accessibility tree. The result is fields a screen reader announces as 'edit text' with no name, and prompts that vanish on input.

<input type="email" name="email" placeholder="Your email address">

<label for="newsletter-email">Email address</label>
<input type="email" id="newsletter-email" name="email"
       autocomplete="email" required>

Shopware's plugin ecosystem (Shopware Store) lets developers add storefront widgets - cookie banners, product comparison, wishlists, quick buy - and these are not held to an accessibility standard. Plugins built from non-semantic <div>/<span> elements add controls with no role, name, or keyboard support, regressing an otherwise compliant storefront.

<div class="wishlist-toggle" data-id="42"
     onclick="toggleWishlist(42)"></div>

<button type="button" class="wishlist-toggle" data-id="42"
        onclick="toggleWishlist(42)"
        aria-pressed="false" aria-label="Add Leather Bag to wishlist">
</button>