Accessibility Overlays vs Source Remediation: What Shopify Merchants Should Verify

“Overlay” and “source-code fix” describe mechanisms, not guaranteed outcomes. A runtime script can provide useful user controls or modify the rendered page. A source change can improve the markup or styles Shopify serves. Either can still miss important barriers.

What a runtime accessibility layer does

A runtime layer loads JavaScript in the visitor’s browser and can add controls or modify the rendered document. Its exact behavior varies by product. Merchants should confirm:

• what happens before and after the script loads;
• which changes are user-selected versus automatic;
• behavior when the script is blocked or unavailable;
• interaction with theme and third-party JavaScript;
• data collection and privacy terms;
• what stops when the service is removed.

Display controls can be a useful supplement for some visitors. They are not a substitute for testing and remediating underlying barriers.

What source remediation does

Source remediation changes the Shopify theme or another supported resource so the served output can change without relying on a separate accessibility script. That has important benefits, but also limits:

• a theme edit stays only in the modified theme;
• theme updates or later edits can overwrite it;
• a different theme does not inherit it automatically;
• a change can fix one state and break another;
• third-party output may not be writable by the merchant’s app;
• code changes still require manual and assistive-technology testing.

The relevant FTC record

In 2025 the FTC approved a final order requiring accessiBe to pay $1 million and restricting certain unsupported automated-WCAG-conformance claims. The FTC announcement is the primary source.

The durable lesson is to demand evidence and reject categorical conformance claims. The order does not prove that all runtime tools are identical or that source-remediation tools guarantee a legal outcome.

A practical Shopify test plan

1. Choose representative product, collection, cart, account, and content journeys.
2. Record the theme version, third-party apps, viewport, and user state.
3. Run automated checks and retain their exact page scope.
4. Test keyboard order, visible focus, dialogs, error handling, and announcements manually.
5. Use relevant assistive technology on the critical purchase path.
6. Inspect source, computed output, and runtime changes separately.
7. Confirm what the tool could not reach, detect, change, or verify.
8. Repeat after theme publication, app changes, and major content updates.

How AccessComply approaches changes

AccessComply scans eligible automated rules on discoverable public storefront pages within crawler limits. For a safely source-mapped candidate, the merchant approves the exact candidate or scoped operation before a supported write.

Supported writes create restore records and run a post-change check. Only confirmed findings are marked resolved. Unsupported, stale, risky, third-party, and judgment-heavy work remains for manual review. Restore requires merchant confirmation because an older value can overwrite later edits.

That workflow is intentionally scoped. It is not a complete audit or a compliance guarantee.

Start with a free automated scan, then validate the most important journeys manually.