Failed CI accessibility checks: keep original evidence before fixing and retesting

A failed accessibility check in CI signals that a gate did not pass, but the key follow-up is identifying the triggering element, the page state tested, and the evidence to compare after changes. The described workflow preserves the original report, generates a separate retest report, and records manual observations alongside automated results. It uses the GatekeeperQA CLI, which runs locally without a hosted account, with scans limited to explicitly listed pages in their initial state and no crawling or interaction testing. Evidence should be uploaded even when the gate fails, with the job failing based on the captured exit code, and PR validation should target the checked-out app or that PR's deployed preview. Passing automated scans do not verify keyboard behavior or resulting states, so manual checks and build, URL, and configuration details should be documented.