accesslint-diff

When to Use

• Compare a requested page's accessibility findings between verified base and candidate revisions.
• Report introduced, fixed and still-present findings without changing application source.

1. Establish isolated snapshots

This package does not bundle the CLI or browser. Verify the current installed tool schema or a reviewed pinned package version first. Do not evaluate $ARGUMENTS or branch/URL text as shell syntax.

1. Resolve the requested base and head to full commit SHAs; identify whether staged, unstaged or untracked content belongs to the candidate.
2. Preserve the user's checkout. Prefer isolated worktrees or recoverable snapshots for base and candidate; do not switch their branch or pop an unrelated stash. A branch mode comparing only committed HEAD must disclose excluded local changes.
3. Use each revision's reviewed lockfile and authorized build procedure. Serve base and candidate on separate local ports, wait for a deterministic ready selector and verify which revision each page actually serves. A fixed sleep is not a readiness check.
4. Audit matching URLs, account state, viewport, selectors, engine version and rule configuration. Keep private snapshots in a fresh owner-only directory, not a predictable shared /tmp filename. Capture the baseline and candidate using the actual supported CLI flags; do not invent commands when integration is unavailable.
5. Compare findings and inspect selector drift or removed content. Record inaccessible states and manual WCAG checks separately. Never promise full restoration without verifying file status and content.

2. Report