Every step of the RemediADA pipeline — from first crawl to compliance certificate — is documented here. No black boxes.
Most scanners run a single axe-core pass on the static HTML and call it done. RemediADA runs six sequential layers. Each layer catches violations the previous ones cannot reach. Findings are deduplicated before they reach your report — one violation appears once.
The scanner parses the serialized HTML of every page and runs axe-core rules against the DOM tree before any JavaScript executes. Missing alt attributes, empty link text, skipped heading levels, and absent form labels are caught here — the violations most commonly cited in ADA demand letters.
After the page fully renders, the scanner reads the browser's computed accessibility tree through Playwright. This catches violations that the raw HTML hides: ARIA roles that contradict the visible DOM, focus order that differs from visual order, and color-contrast failures calculated from the browser's actual resolved styles.
Automated tab-sequence traversal verifies every interactive element is reachable by keyboard alone, has a visible focus indicator, and can be activated without a pointer. Focus traps — dialogs that capture and never release keyboard focus — are flagged as critical.
The scanner drives a headless assistive-technology layer and records the announcement sequence a user of NVDA or JAWS would hear. Misleading button labels, unlabeled landmark regions, and form fields whose error messages are not announced are caught at this layer.
Menus, accordions, carousels, modals, and tab panels are opened before scanning. Content gated behind user interaction — the most common source of missed violations in static scanners — is fully exercised before any rule is evaluated.
Session cookies, authenticated routes, and lazy-loaded content are handled across the full crawl. Violations that only appear on page two of a multi-step form, or inside a members-only section, are included in the audit. Each finding is deduplicated across layers so a single violation appears once, not four times.
The core architectural constraint of RemediADA is the Persistence Limitation: every remediation must modify source content via the platform’s own API. No JavaScript overlays. No runtime DOM mutation. No proxy-served rewrites. If RemediADA were disconnected today, every fix already deployed would remain in place.
Each platform adapter calls the platform’s own documented API. WordPress fixes go through the WordPress REST API. Shopify fixes go through the Shopify Admin GraphQL API. Webflow through the Webflow CMS API. GitHub-hosted sites through pull requests. Raw HTML sites through SFTP source push.
The fix is written to the database row, CMS content record, or version-controlled source file — whichever is the platform’s source of truth. Not to the rendered HTML the visitor receives, and not to a JavaScript layer that intercepts it.
The remediation engine generates a candidate fix and a confidence score. Fixes above the confidence threshold deploy automatically. Fixes below it go to a human-review queue before any source write occurs. The threshold is configurable per customer. No fix ever deploys without passing either automated confidence gating or human approval.
Every fix is tested in a sandbox environment before it reaches production. Each deployed change is stored as an attributed changeset. Any single fix can be individually reversed without touching unrelated changes — rollback is per-changeset, not per-deployment.
New content, product updates, and theme changes introduce fresh violations after remediation. Monthly re-scans detect compliance drift on a per-criterion basis and trigger automatic re-remediation on approved violation patterns, so compliance does not decay between audits.
A compliance claim is only as strong as its evidence. Every scan, every fix, and every post-deployment verification is recorded in an ordered chain. The chain is designed to withstand legal scrutiny — each step references the one before it, and the whole chain anchors to public infrastructure no single party can alter.
Every scan is assigned a unique run ID. The complete violation list, per-criterion WCAG references, severity ratings, and element selectors are written to a tamper-evident record at scan completion.
Each deployed fix is stored as a six-field changeset: WCAG criterion, platform and deployment mechanism, page-section locator, content hash before and after, evidence chain anchor, and originating scan context. Changesets support selective rollback to any prior state.
After every source-write, a read-only verification fetch re-scans the origin. The scanner confirms the fix is present in the live HTML before closing the changeset. This is not a poll — it is a re-run of the same detection layers used in the initial audit.
Scan events, fix deployments, and verification results are written to a permissioned audit ledger (Tier 1) and rolled up to public blockchain anchors (Tier 2 and 3). A compliance certificate prints the Tier-1 hash in its footer so any recipient can verify the chain independently.
RemediADA scores every site against a litigation-risk model that weighs industry, jurisdiction, page count, and ADA plaintiff activity in the site’s region. This score is a transparency tool — it tells you where you stand relative to sites that have been targeted, not a prediction of whether you will be sued. The score does not constitute legal advice.
