What's an overlay, and what's source-code remediation?
An accessibility overlay is a third-party JavaScript widget installed via a single script tag. Examples include accessiBe's accessWidget, AudioEye, UserWay, EqualWeb, and a handful of smaller products. Once loaded, the widget attempts to apply accessibility fixes to the rendered DOM — adjusting alt attributes, ARIA roles, contrast, and focus behavior — without modifying the site's underlying source.
Source-code remediation means an accessibility team (like ours) audits a site against WCAG 2.2 AA, then edits the actual HTML, CSS, JavaScript, and templates to bring them into conformance. The changes live in the codebase. There is no widget, no script tag, and no subscription.
When an overlay genuinely makes sense
Overlays aren't useless — they're just frequently mis-sold. There are situations where a widget-based approach is a defensible choice:
- Very large sites with high content velocity. News publishers, marketplaces, and enterprise catalogs that change by the hour often can't remediate faster than they publish. Continuous automated monitoring (even imperfect) catches low-hanging issues between audits.
- Sites where you can't edit the templates. Some fully hosted platforms, legacy CMSes, or vendor-controlled systems simply don't expose the code you'd need to modify. If a script tag is the only intervention available, a widget is the intervention available.
- As a supplement to remediated source. Some larger organizations use an overlay on top of fully remediated code for ongoing user preferences (font size, contrast, stop animations). That's a reasonable role — not the same as compliance.
None of those describe a typical owner-operated business with a WordPress, Webflow, or Shopify site that does expose templates. For that profile, source-code remediation is cheaper and permanent.