1. The Immediate Duty to Preserve Electronically Stored Information (ESI)
When a commercial entity receives an ADA Title III demand letter or federal complaint alleging website accessibility barriers, its immediate operational instinct is often to instruct internal developers or external web agencies to "patch the issues immediately" on the live production server.
Courts generally treat the duty to preserve electronically stored information (ESI) as starting once litigation is reasonably anticipated. A website’s live pages, templates, stylesheets and scripts can be part of that ESI; your counsel decides what must be preserved.
Overwriting them in place, without first recording a baseline, changes the site from the state it was in when the plaintiff says they visited. Whether that raises a preservation issue under Federal Rule of Civil Procedure 37(e) is for counsel to assess.
2. What is lost when the live site is patched in place
Without a recorded baseline:
- The original state is gone: once the live pages change, nobody can reconstruct exactly what a visitor using a screen reader met on the date in question, including whether the flagged issues actually blocked them.
- Rule 37(e) remedies: if ESI that should have been preserved is lost and cannot be restored or replaced, a court may order measures to cure the prejudice; only on finding an intent to deprive may it presume the information was unfavorable, instruct the jury accordingly, or dismiss the action or enter a default judgment (Fed. R. Civ. P. 37(e)(1)–(2)).
- Harder to show what changed and when: dated captures with file hashes give a clear before-and-after record that counsel can use if it helps.
3. The Engineering Solution: Spoliation-Safe Isolated Staging Sandboxes
To resolve the operational conflict between preserving baseline evidence and promptly remediating accessibility barriers, software engineering protocols must support defense counsel through an isolated sandbox remediation architecture:
Capture of WARC web archives, SHA-256 cryptographic hashes, headless browser MHTML snapshots, and Git commit freezes of live production templates before any code modification occurs.
The entire web application is cloned into a private, password-protected staging sandbox with no public search indexation, preventing disruption to active customers while preserving production server logs intact.
Engineers remediate template markup, ARIA roles, and form labels, execute automated axe-core regression tests, and prepare Technical Documentation for defense counsel prior to a controlled production deployment.
4. Steps to discuss with your counsel
Before any fixes start, these are the technical steps we usually suggest raising with counsel:
- Place an immediate technical freeze on continuous integration and deployment (CI/CD) pipelines touching challenged public templates.
- Ask counsel whether an independent forensic firm should also capture the site before anything changes.
- Capture dated snapshots, with SHA-256 file hashes, of the pages and user flows named in the complaint.
- Execute all WCAG 2.1 Level AA source-code remediations exclusively in an isolated staging environment until reviewed by counsel.
Record a baseline, then remediate on staging
We record a dated baseline (web archive, screenshots, response headers and SHA-256 file hashes) before any change, then remediate on an isolated staging copy, typically within 48–72 hours.
Request Staging Sandbox & Baseline Audit →