Fixes — source-code remediation

Most tools stop at a report. Wholisphere is being built to close the loop the right way: for each issue a scan finds, our agent proposes a fix to the real source that serves your site — a pull request against your repository, or a change made through your CMS’s own tools — which you review and apply, and which we then verify by re-scanning.

In development

The source-code fix engine is under active development. Scanning and VPAT generation are available today; the automated-fix workflow described here is rolling out. This page describes how it works by design.

What “fix” means here

A Wholisphere fix always changes the canonical source of truth for your site:

• a pull request against your Git repository (for teams with a repo + CI), or
• a change through your platform’s own tools (a WordPress/Shopify/Webflow write, or an edit the agent makes in your site editor).

The test we hold ourselves to is simple: if you removed Wholisphere entirely, the fix would still be there. It lives in your code or your CMS — not in a script that patches the page in your visitors’ browsers.

What we will never do

• No overlay. We do not load a script that rewrites your page’s accessibility at run time.
• No client-side injection. Nothing is patched in a visitor’s browser to satisfy a compliance claim.
• No faked results. If an issue needs access you haven’t granted, or a fix that isn’t possible on your platform, we tell you plainly and it stays open in your report — we never mark it resolved by papering over it.

These runtime “accessibility overlays” are exactly what we reject: they’re fragile, they don’t fix your source, and they’ve become a legal liability. Wholisphere fixes the real thing.

How it works

scan finds the issue  →  it's pinned to the exact element
   →  the agent proposes a fix to your real source (repo PR / CMS change)
      →  you review and apply it (or let the agent apply it, with access granted)
         →  a re-scan verifies the served page now passes

1. Scan. Every issue is recorded against a stable selector for the offending element.
2. Propose. The agent turns that issue into a concrete source change, with full context (the element, the WCAG criterion, and the evidence).
3. Review & apply. You review the change and apply it — or, with access granted, the agent opens the PR / makes the CMS change for you. You stay in control by default.
4. Verify. A re-scan confirms the fix landed in the served output. Only then is the issue marked resolved.

The honest boundary

Some issues can’t be fixed without access we don’t have, or on platforms that lock the relevant part of the template. In those cases you get two clear paths — replace the locked piece with something we can keep compliant, or an openly disclosed open issue in your VPAT. We would rather tell you the truth than hide an unfixed issue behind a runtime patch.

Where it shows up

• Fixes page (dashboard) — review proposed source changes and their verification status.
• Your VPAT — reflects exactly what the scan found. Issues we haven’t fixed at the source stay openly disclosed.