Ecwid Accessibility Checklist 2026 | WCAG 2.1 AA & EAA Compliance

Last updated: 2026-05-23

Ecwid by Lightspeed is unusual among the platforms in this list because it is not a website builder, it is a storefront you embed inside one. You drop a small script onto an existing WordPress, Wix, Squarespace, or hand-coded page and Ecwid renders the catalog, product pages, cart, and checkout client-side, inside that host page. That embedding model creates accessibility problems you do not get with a self-contained store. The injected store has its own heading structure that can collide with the host page's headings, producing duplicate H1s or an outline that jumps around. Catalog browsing, category filtering, and 'load more' all update the page with JavaScript and frequently do so without telling a screen reader anything changed, so a blind shopper taps a filter and hears silence. Product option pickers (size, color) are often built as clickable styled boxes rather than real radio buttons or a select, so their state is invisible to assistive technology. The cart slides out as an overlay that may not move or trap keyboard focus. And because store owners import products in bulk, image alt text is commonly empty or just a repeat of the product title. Ecwid has worked on accessibility and its newer storefront is better than the legacy one, but the embedded, dynamic nature of the store means the host page and the widget have to be tested together, not separately. With ADA Title III lawsuits in the US heavily concentrated on e-commerce, and the European Accessibility Act now requiring accessible e-commerce for businesses selling to EU consumers, an embedded Ecwid store carries the same legal exposure as any standalone shop. This checklist walks through the failures we see most often on Ecwid storefronts and how to address each one.

Common Accessibility Issues

serious

Catalog, Filtering, and 'Load More' Updates Not Announced

WCAG 4.1.3

Ecwid renders the storefront client-side, so browsing a category, applying a filter, sorting, or pressing 'load more' replaces or adds products without a full page load. By default these changes are not announced through an ARIA live region, so a screen reader user who interacts with a filter has no feedback that the product list changed, how many results there are, or that anything happened at all. The same is true when an item is added to the cart from a listing.

How to fix:

Provide a polite status message whenever the product list or cart changes, for example 'Showing 24 products' after a filter or 'Item added to cart' after an add. Ecwid exposes JavaScript storefront events (such as the page-loaded and cart-changed callbacks in its API) that you can hook to update a visually-hidden aria-live="polite" region you place in the host page. Confirm with a screen reader that filtering and pagination produce an audible result count.

Before 
<!-- product grid swaps silently on filter, no status region -->
<div id="ecwid-store"></div>
After 
<div id="ecwid-store"></div>
<div aria-live="polite" class="sr-only" id="store-status"></div>
<script>
  Ecwid.OnPageLoaded.add(function (page) {
    if (page.type === 'CATEGORY') {
      document.getElementById('store-status').textContent =
        'Product list updated.';
    }
  });
</script>
serious

Product Image Alt Text Empty or Just the Product Title

WCAG 1.1.1

Store owners import or upload product photos in bulk, and Ecwid does not force a meaningful alt value per image, so gallery and thumbnail images often have empty alt text or alt that simply repeats the product name already announced as the heading and link. Shoppers who rely on a screen reader cannot tell a front view from a detail shot, cannot read text printed on packaging, and get no help distinguishing color or pattern variants shown only in the photos.

How to fix:

Set descriptive alt text on each product image in the Ecwid product editor's image settings, describing what the photo shows beyond the product name (for example 'Navy hoodie, back view showing embroidered logo'). For purely decorative additional shots, leave alt empty so they are skipped rather than repeating the title. Where a variant's only differentiator is shown in the image (a color), make sure that information is also available as text in the option label.

serious

Option Swatches Built as Clickable Divs, Not Real Controls

WCAG 1.3.1

Color and size selectors on product pages are frequently rendered as styled boxes or swatches that respond to clicks but are not exposed as radio buttons or a select element. Their selected state is shown only with a border or highlight, which is invisible to screen readers, and color-only swatches with no text label leave a blind shopper unable to know which color they are choosing. Keyboard users may also be unable to move between swatches with arrow keys as they would expect from a radio group.

How to fix:

Prefer Ecwid's dropdown (select) option type for variants whose accessible behavior is built in, or ensure swatch-style options expose a proper radio group: role="radiogroup" with role="radio" and aria-checked on each swatch, arrow-key navigation, and a programmatic label on every option (the color or size name, not just a color fill). Never rely on a highlight border alone to convey which option is selected, and never convey a variant difference through color alone.

Before 
<div class="swatch" style="background:#1b3a6b"></div>
<div class="swatch selected" style="background:#7a1f1f"></div>
After 
<fieldset>
  <legend>Color</legend>
  <label><input type="radio" name="color" value="navy"> Navy</label>
  <label><input type="radio" name="color" value="maroon" checked> Maroon</label>
</fieldset>
serious

Slide-Out Cart Without Focus Management

WCAG 4.1.2

Adding an item often opens a slide-out cart drawer or mini-cart on top of the page. If the drawer does not move focus into itself, does not trap focus while open, and is not announced as a dialog, keyboard users keep tabbing through the store behind the drawer and screen reader users do not learn the cart opened or what it now contains. Closing the drawer may also dump focus back to the top of the page instead of where the shopper was.

How to fix:

Expose the cart drawer with role="dialog" and aria-modal="true", give it an accessible name, move focus to the drawer (its heading or first control) when it opens, trap Tab within it, close it on Escape, and return focus to the element that opened it. Mark the page behind it inert/aria-hidden while open. If you cannot change the drawer markup directly, consider configuring Ecwid to navigate to a full cart page instead of an overlay, which sidesteps the focus-trap requirement.

moderate

Embedded Store Heading Hierarchy Colliding With the Host Page

WCAG 1.3.1

Because Ecwid is injected into a host page that already has its own H1 (the page title) and section headings, the store's own headings (category name, product name, 'Related products') can introduce a second H1 or break the host page's outline by appearing at the wrong level. Screen reader users navigating by heading then encounter a jumbled structure that does not reflect the actual page sections.

How to fix:

Embed the store inside a host page whose own heading levels leave room for the store's content. If the page H1 is the store/category title, make sure the host template does not also output a competing H1, and place the Ecwid embed under an appropriate heading level. Check Ecwid's storefront settings for control over the store title heading level, and audit the combined page outline with a heading-map tool rather than viewing the store and the page in isolation.

serious

Checkout Fields With Placeholder-Only Labels

WCAG 3.3.2

The checkout collects name, address, email, and payment details. When fields rely on placeholder text instead of persistent visible labels, the label vanishes as soon as the shopper types, screen readers may not announce it, and the light placeholder gray usually fails contrast. At the highest-stakes step of the purchase, users who depend on labels can lose track of which field they are in, and errors that are not tied to their field are hard to locate.

How to fix:

Confirm every checkout field renders a real, persistent label associated with its input, that required fields are marked with aria-required (not color alone), and that validation errors are associated with their field via aria-describedby and announced. Use the newer Ecwid storefront, which has stronger checkout markup than the legacy one, and test the full checkout flow with a screen reader and with the keyboard only, including the payment step.

moderate

Quantity Steppers and Icon Buttons Without Accessible Names

WCAG 4.1.2

Quantity selectors rendered as plus/minus icon buttons, and other icon-only controls such as a cart or wishlist glyph, frequently have no text and no aria-label, so a screen reader announces only 'button' with no indication of what it does. A shopper cannot tell the increase button from the decrease button, or that an icon is the cart at all.

How to fix:

Give every icon-only control a clear accessible name with aria-label, for example 'Increase quantity', 'Decrease quantity', and 'View cart'. Ensure the current quantity value is exposed as text and updates are announced. Verify each control is reachable and operable with the keyboard and that its purpose is clear from the screen reader announcement alone.

Before 
<button class="qty-plus">+</button>
<button class="qty-minus">&minus;</button>
<button class="cart-icon"><svg ...></svg></button>
After 
<button class="qty-plus" aria-label="Increase quantity">+</button>
<button class="qty-minus" aria-label="Decrease quantity">&minus;</button>
<button class="cart-icon" aria-label="View cart, 2 items"><svg aria-hidden="true" ...></svg></button>

Ecwid by Lightspeed-Specific Tips

  • Always test the host page and the embedded store together on the published site, not separately. Many Ecwid issues (duplicate H1s, focus escaping into the host page) only appear when the widget and the page are combined.
  • Use the newer Ecwid storefront rather than the legacy one. The current storefront has materially better markup for product pages and checkout; if you are on an old embed, upgrading is the cheapest accessibility win available.
  • Hook Ecwid's storefront JavaScript API events (page-loaded, cart-changed) to drive a visually-hidden aria-live region in your host page, since the store's dynamic updates are otherwise silent to screen readers.
  • Prefer the dropdown option type over swatch-only variant pickers when a variant cannot be made an accessible radio group, and make sure every color option also has a text name so it is not conveyed by color alone.
  • If the slide-out cart cannot be made into a proper focus-trapped dialog, configure the store to send shoppers to a full cart/checkout page instead, which removes the overlay focus requirement entirely.

WAVE Browser Extension

WebAIM's free extension runs on the live combined page (host site plus the embedded Ecwid store), flagging missing alt text, unlabeled controls, contrast failures, and heading-structure problems that only appear once the widget is rendered.

axe DevTools

Deque's scanner reports WCAG-referenced issues on the rendered storefront, useful for catching ARIA and name/role/value problems in the dynamically generated product, cart, and checkout markup.

Ecwid Storefront JS API

Ecwid's official storefront JavaScript API exposes events such as OnPageLoaded and OnCartChanged that you can use to announce dynamic catalog and cart updates through an aria-live region in the host page.

Ecwid Accessibility: Default Behavior vs. What WCAG Needs

Plugin / Tool Store ElementCommon Ecwid DefaultWhat WCAG 2.1 AA NeedsSeverity If Unfixed
Filtering / load more 4.1.3 Product list swaps silently via JSaria-live status announces the change / result countSerious
Product image alt 1.1.1 Empty or repeats the product titleDescribes what the photo shows; decorative shots emptySerious
Option swatch 1.3.1 Clickable div, color-only, state shown by borderReal radio group or select with text labelsSerious
Slide-out cart 4.1.2 Overlay opens, focus stays on pagerole=dialog, focus moved in and trapped, restored on closeSerious
Quantity stepper 4.1.2 +/- icon buttons with no accessible namearia-label on each control; value exposed as textModerate

Frequently Asked Questions

Does embedding Ecwid make my whole site fail accessibility?

It can. Because Ecwid is injected into your existing page, any inaccessible part of the storefront, an unlabeled option swatch, a silent cart drawer, an unannounced filter, becomes part of your page and counts against it in an audit or a lawsuit. The store and the host page are evaluated together, so a clean host page with an inaccessible embedded store is still non-compliant. This is general information, not legal advice.

Is the newer Ecwid storefront more accessible than the old one?

Yes, generally. Ecwid's current storefront has improved markup for product pages, options, and checkout compared with the legacy storefront, so upgrading is usually the single most cost-effective improvement. It still does not remove your responsibility to set meaningful image alt text, announce dynamic updates, and test the combined page, but it gives you a better baseline to work from.

How do I make Ecwid's dynamic catalog updates accessible to screen readers?

Add a visually-hidden aria-live="polite" region to your host page and update its text whenever the store changes, using Ecwid's storefront JavaScript API events (such as OnPageLoaded and OnCartChanged). That way filtering, sorting, pagination, and add-to-cart actions produce a spoken result like 'Product list updated' or 'Item added to cart' instead of silence.

Further Reading

Other CMS Checklists