When the accessibility problem is not your theme: apps

Run an honest audit on almost any Shopify storefront and a pattern shows up: a large share of the violations were not written by the theme developer and cannot be found anywhere in the theme code. They arrive through installed apps. Review stars without accessible names, popups that trap keyboard focus, cookie banners with 2:1 contrast, chat bubbles with no label. On stores we scan it is common to see a third or more of all violations traced to apps.

Why this is the merchant's problem

The shopper sees one page. The European Accessibility Act judges one service: yours. The obligations fall on the provider of the e-commerce service, which is the merchant, not on each vendor whose JavaScript happens to run on the page. In other words, you are liable for markup you have never seen, shipped by vendors you pay. That is uncomfortable, and it is how the directive works. Background in the EAA guide for Shopify stores.

Why most audits miss it

Manual reviews and theme-focused tools read your theme code, and your theme code is clean. App markup is injected at render time through app embeds and app blocks, so it only exists on the live page. If your audit does not run against the storefront a shopper actually receives, the app layer is invisible to it, and so is a third of your risk.

Finding the culprits

App embeds and app blocks leave recognisable traces in the rendered page, so each failing element can be traced back to what injected it. Doing this by hand means reading the DOM of your live storefront section by section. Doing it automatically is exactly what we built HewnScan for: it scans the live page, runs 26 checks mapped to WCAG 2.1 A/AA and EN 301 549, and names the app behind each violation instead of dumping everything on your theme.

What to do with an offending app

1. Check its settings first. Many violations are configuration, not code: a default colour with poor contrast, an optional label left empty.
2. Ask the vendor. A short support message naming the failing element and the WCAG criterion often gets a fix scheduled; accessible markup is in the vendor's interest too.
3. Replace it. Most app categories have more than one credible vendor. If yours will not fix a barrier, one of their competitors already has.
4. Patch the symptom in theme CSS where possible, as a stopgap, and note it in your accessibility statement.

Frequently asked questions

An app caused the violation. Why is it my problem?

Because the law judges the service the shopper uses, and that service is your storefront. The EAA obligations fall on the provider of the e-commerce service, which is the merchant, regardless of which vendor generated a given piece of markup.

How do I know which app caused an issue?

By tracing the failing element back to what injected it. App embeds and app blocks leave recognisable traces in the page; an audit that understands them can attribute each violation to a specific app instead of dumping everything on your theme.

The app vendor won't fix their markup. What are my options?

Three, in order of effort: configure the app differently (many issues are a setting, like a low-contrast default colour), replace the app with an accessible alternative, or patch the symptom in your theme CSS where possible. Keeping the app unchanged and staying exposed is also a choice, but make it consciously.