Accessibility Overlays Won't Pass a WCAG Audit. Here's What Actually Will.

If you've shipped a site in the last few years, you've probably been pitched an accessibility "overlay" — a single script that promises instant ADA compliance with a floating widget in the corner. It's an appealing offer. It's also, for the failures that matter most, not how accessibility works.

The reason is structural. An overlay runs on top of your rendered page. Assistive technology — screen readers, switch devices, voice control — consumes the underlying DOM and the accessibility tree the browser builds from it. If your markup is broken, a widget layered above it doesn't repair the tree. The user still hits an unlabeled button. The contrast still fails. And the legal exposure that site owners worry about doesn't go away, because compliance is measured against the actual WCAG success criteria, not against the presence of a widget.

So let's talk about what an audit actually checks, and how to fix the common failures at the source.

The failures you'll see most often

Across real-world audits, the same handful of WCAG 2.2 issues come up again and again:

1. Insufficient color contrast (WCAG 1.4.3). Normal-size text needs a contrast ratio of at least 4.5:1 against its background; large text needs 3:1. Light-gray-on-white placeholder text is the classic offender.
2. Images missing alt text (WCAG 1.1.1). Every meaningful image needs a text alternative. Decorative images need an explicitly empty alt so screen readers skip them.
3. Controls with no accessible name (WCAG 4.1.2). An icon-only button with no label is announced as just "button." Users have no idea what it does.
4. Form inputs with no associated label (WCAG 1.3.1, 3.3.2). A placeholder is not a label. It disappears on focus and isn't reliably announced.

Fixing them in the markup

Most of these are quick edits once you can see them. A few concrete examples:

<!-- Before: icon button with no accessible name -->
<button class="icon-btn">
  <svg aria-hidden="true">...</svg>
</button>

<!-- After: name it -->
<button class="icon-btn" aria-label="Close dialog">
  <svg aria-hidden="true">...</svg>
</button>

<!-- Before: input relying on placeholder -->
<input type="email" placeholder="Email address" />

<!-- After: real associated label -->
<label for="email">Email address</label>
<input id="email" type="email" />

For images, decide whether each one carries information:

<!-- Meaningful image -->
<img src="chart-q3.png" alt="Q3 revenue up 18 percent over Q2" />

<!-- Decorative image, intentionally skipped -->
<img src="divider.png" alt="" />

Contrast is mostly a design-token problem. Pick foreground and background values that clear 4.5:1, verify the ratio, and apply them consistently rather than patching one element at a time.

A practical workflow

The fastest loop I've found is: scan, fix at the source, re-scan.

• Scan the page against WCAG 2.2 to get a specific list of failing elements, each tied to a success criterion.
• Read the fix for each one so you're editing markup, not guessing.
• Fix the highest-impact items first — usually contrast and missing names, because they affect the most users.
• Re-scan to confirm the items actually cleared, and to catch anything you introduced while editing.

Automated scanning won't catch everything — judgment calls like whether alt text is meaningful, or whether a custom widget's keyboard interaction makes sense, still need a human. But a good scan removes the noise so your manual time goes to the things that genuinely need it.

If you want a quick way to run that loop, FixMyWeb scans a page against WCAG 2.2 / ADA, flags issues like contrast and missing alt text, and explains how to fix each one — no overlay, no plugin pretending the work is done. It's free to try, so you can point it at a URL and see your real exposure before someone else does. The honest version of accessibility is always the one where you can show exactly what failed and exactly what you changed.

Full disclosure: I build FixMyWeb, a web accessibility auditor (WCAG 2.2 / ADA) that flags issues and explains how to fix each one. It is free to try at https://fixmyweb.dev.