♿ Free · no signup · no app install · read-only
Your accessibility widget is not an accessibility fix.
We load your storefront exactly as it is served, name the overlay vendor whose script is loading on it (accessiBe, UserWay, EqualWeb, AudioEye and other widgets we fingerprint by their own script host), and then count the code-level defects still sitting in that HTML — images with no alt, fields with no label, buttons with no name. Whatever a widget does in the browser afterwards, it does not change the code your server sent.
Based on publicly available data only. Informational, not legal advice.
What this checks
- Which overlay vendor's script the storefront loads — accessiBe, UserWay, EqualWeb, AudioEye, Max Access and others, each matched on the vendor's own domain or loader global, never on a stray English word
- Overlay leftovers in the HTML itself: vendor container divs, vendor iframe ids and widget class names — plus controls merely labelled like an accessibility menu, which we report without pinning on any vendor
- Images served with no alt attribute at all, counted across the home page and one product page
- Form fields with no label, and buttons and links that reach a screen reader with no name
- A skip-to-content link, the lang attribute on <html>, and whether the viewport meta blocks pinch-zoom
- Whether a same-domain accessibility statement is linked from the home page and actually returns a page
FAQ
I already have an overlay. Doesn't that cover me?
No standard and no regulator recognises a widget as compliance. The requirements are written against WCAG — EN 301 549, the European standard for accessible ICT and the harmonised standard under the EU's public-sector Web Accessibility Directive, incorporates WCAG 2.1 Level AA for web content — and WCAG is about the code that gets delivered. A widget runs in the browser afterwards; it does not change what your server sends, which is the copy an auditor reads. In January 2025 the US Federal Trade Commission announced a $1 million settlement with accessiBe over claims that its widget could make a website WCAG-compliant. We are not lawyers and none of this is legal advice.
Why do some checks say “could not tell”?
We read the HTML your server returns; we do not run JavaScript. We also strip HTML comments, <script>, <template> and <noscript> bodies before counting, because a tag in a comment or an un-cloned template is not something a shopper meets. If your theme builds its images, forms or navigation in the browser, there is nothing for us to count and we say so instead of inventing a number.
Is this a full WCAG audit?
No, and nothing automated is. A static scan covers only part of WCAG — colour contrast, focus order, keyboard traps, screen-reader flow and error handling all need a person with a keyboard and a screen reader. Treat a clean result as “no obvious machine-detectable defects on the pages we read”, not as “accessible”.
Want the overlay taken out and the theme actually fixed?
We are a Shopify studio. The audit is free; the fix is yours to make — or ours to ship.
Other free tools
- BuilderRent — How many of your pages are built by an app instead of your theme?
- SpeedTax — Which apps are taxing your homepage the hardest?
- FlickerScan — Your A/B test hides the whole page to stop the flicker. For how long?
- RechargeEscape — Six of the eight subscription apps we check take a cut of every recurring order. Shopify's own one does not.
- See all 29 free tools