Overlay Tools vs Real Remediation: Why It Matters for Your Defense

Between 2018 and 2022, overlay accessibility products reached hundreds of thousands of small business websites. The pitch was simple: paste one line of JavaScript and your site is compliant. The reality, which courts and disability advocates have spent years documenting, is that overlays cannot deliver real WCAG conformance and in some cases make accessibility worse.

What an overlay actually does

When a typical overlay loads, it injects a floating button into the page and adds a layer of JavaScript that attempts to modify the live DOM at runtime. Common runtime changes include:

• Auto-generating alt text for images using machine learning, often inaccurate
• Adjusting color contrast at the user's request only after they open the overlay
• Overriding font sizes, line spacing, and text alignment via local style injection
• Adding a screen reader controlled by the overlay rather than the user's existing assistive technology
• Rewriting ARIA attributes on top of the host site's existing markup

Why this is structurally limited

Three structural problems make overlays unable to substitute for real remediation:

1. The overlay is opt-in, but WCAG is on by default

Most overlays require a user to find and click a floating widget before any adjustment happens. WCAG conformance is not based on what is reachable through a vendor's settings menu. It is based on what every user encounters by default.

2. Auto-generated content is not the same as authored content

ML-generated alt text might say a man in a blue shirt smiling when the image is a product photo of a tennis racket. The user cannot tell the difference. Inaccurate descriptions are not a minor inconvenience for screen reader users, they are misinformation.

3. Two screen readers in one tab compete

When a user already runs JAWS, NVDA, or VoiceOver, an overlay-injected screen reader competes with their existing software. The overlap creates duplicate announcements, focus jumps, and broken keyboard navigation. The National Federation of the Blind has documented this in detail.

What real remediation looks like

Real remediation happens in your source code, not at runtime. The deliverables are concrete:

• Alt text written by humans who know what each image actually means in context
• Focus styles, semantic landmarks, and heading hierarchy authored into the design system
• Form fields with programmatically associated labels and error messages
• Keyboard interaction patterns following the WAI-ARIA Authoring Practices
• Color tokens chosen to satisfy 4.5 to 1 contrast against their backgrounds
• Reduced-motion media queries respected on all animated elements

When a court sees a code-level remediation log paired with dated automated scans and an annual manual audit, the picture is unambiguous: the business has integrated accessibility into its engineering practice. When a court sees a single overlay script tag dated to the day before the lawsuit was filed, the picture is also unambiguous, in the other direction.

Where Invoset fits

Invoset is not an overlay. We do not modify your site at runtime. We scan your DOM with the industry-standard axe-core engine, surface specific findings tied to your source code, suggest authored fixes, and produce dated reports your attorney can use as evidence of effort. The badge we offer is a link back to your latest scan, not a runtime widget that overrides your design.