Accessible or Not?
All articles

6 min read

Switching From an Overlay to Code Level Fixes

Switching from an overlay to code level fixes: a migration roadmap with contract checks, removal, scanning, fixes, and a retest plan.

  • switch from overlay to code fixes
  • overlay to code fixes
  • switch accessibility tool
  • code level fixes
  • wcag 2.2 aa
  • accessibility tools

Switching from an overlay to code level fixes is a migration, not a single click. An overlay adjusts the page at run time, while code fixes change the source code itself. The gap between the two is where a site can sit uncovered: the overlay removed, the code fixes not yet landed, and visitors meeting the same barriers the overlay used to adjust. Run the switch in the order below, keep the old tool running until the new fixes are tested, and only then remove it. A switch done in that order never leaves the site worse than it was.

Week one: read the contract, and scan the site as it is

Start with the contract for the current tool: its length, its renewal date, its notice period, and what happens to reports and settings if you leave. Tell readers plainly to check their own contract terms, because terms differ by vendor and by plan, and a switch that ignores a renewal date can cost a full term. If you have received a demand letter or been sued, talk to a qualified attorney before changing anything about the site, and pass the attorney the scan and fix list from this roadmap.

Next, scan the site twice: once with the overlay running, and once with a plan for how the site looks without it. The first scan shows what visitors currently meet. The second view, from a staging copy or a preview without the script, shows the code underneath. Axeazy's free scan runs in 60 seconds with no signup and no card, and the scan on the homepage covers the page you enter. Save both reports with their dates. The pair is the baseline for the whole migration: what the overlay adjusted, and what the code still needs.

Week two: fix the code, while the overlay still runs

Work the fix list in code, in this order: labels on forms, names on buttons and links, heading order, keyboard order, and alt text on images. For sites with a GitHub repository, Axeazy sends fixes as a real pull request with a visible code diff that the owner or developer reviews and merges. For WordPress sites, Axeazy's free plugin applies three render-time fixes: a skip navigation link, a page language attribute, and an alt text fallback. For Shopify stores and other sites with no repo, Axeazy scans the site and gives a guided checklist with computed fix values to apply by hand. Colour contrast is detected and a correct colour is calculated, but a visible colour change is never applied without owner approval, so plan an approval step for any colour change.

Keep the overlay running during this week. Its run-time adjustments still help visitors while the code fixes land, and removing it early only exposes barriers before the fixes are ready. Test each fix on a staging copy first: move through the changed pages with a keyboard only, and confirm focus is visible and never disappears. The scan behind the fixes runs 98 automated checks against WCAG 2.2 AA, grouped into 14 categories, and every scan and fix is recorded with a date and time.

Week three: retest without the overlay, then remove it

When the fix list is done, retest the site with the overlay switched off on a staging copy. Run the scan again, run the keyboard check again, and compare the new report with the baseline from week one. The new report should show the same pages in better shape without the script running. If it does not, the fix list is not done, and the overlay should stay on until it is. Only when the retest passes should you remove the overlay from the live site, following the removal steps for your platform, and clear every cache so no cached page keeps showing it.

After removal, run the scan on the live site and save the dated report. That report, beside the baseline and the retest, is the migration record: what the site looked like with the overlay, what was fixed in code, and what the live site looks like without it. Weekly monitoring on paid plans then catches new problems after later updates, so the migration does not decay in a month.

What the switch costs, and what it saves

Price the switch on the new tool's terms, not the old one's. Axeazy lists Starter at about $29 a month, Pro at about $79 a month, and Agency at about $199 a month or $1,799 a year, with paid prices shown at checkout and an annual saving of 20 to 25 percent. Check those figures on Axeazy's pricing page on the day you switch. Add developer time for reviewing pull requests or applying a checklist, and add a retest after fixes. The saving is not only the monthly difference. It is a site whose barriers are gone from the code, a dated record of the work, and a report that still reads true when the script is off.

One reason buyers make this switch is the FTC record, read factually. In January 2025 the FTC announced a proposed $1 million order settling allegations that accessiBe misrepresented its tool's ability to make any website conform to WCAG, and that third-party articles and reviews were formatted to look impartial without disclosing material connections. The final order was approved in April 2025. That record is about marketing claims and disclosure, and it is a reason to ask any vendor, old or new, for evidence in writing: a sample report, a sample diff, and a retest report.

For the WordPress removal steps, read remove an accessibility overlay from WordPress, and for the Shopify removal steps, read remove an accessibility widget from Shopify. For the comparison behind the switch, read overlay vs code fixes: which should you buy.

FAQ

Should I remove the overlay first, then fix the code?

No. Fix the code first, retest without the overlay on a staging copy, and only then remove it from the live site. Removing first leaves visitors meeting barriers the code fixes have not yet removed.

How long does a switch take?

Three weeks for a small site: one week to read the contract and scan, one week to fix and test, one week to retest, remove, and rescan. A site with a checkout path, many templates, or a demand letter should add a week for manual testing and legal review.

What if the retest without the overlay is worse?

Keep the overlay on, and treat the retest as a fix list, not a failure. The retest shows exactly which code items are still open. Fix those, retest again, and remove the overlay only when the retest passes.

Last checked: October 31, 2026 Sources: FTC January 2025 press release; W3C WCAG 2.2; ADA.gov web guidance; Axeazy capabilities and pricing pages.

Run Axeazy's free scan on your homepage today for the baseline report, then follow the three week order above.

Your turn

Is your own site accessible or not?

Axeazy scans your real pages for WCAG issues like the ones in this deck and opens code fixes, not an overlay. Free scan in 60 seconds, no credit card.

Scan my site free