FOR DEVELOPERS, QA AND DELIVERY TEAMS

Accessibility retesting: a checklist for your next fix

A lower issue count is useful only when you know what changed and what was actually tested.

Published October 4, 2026 · GatekeeperQA

Accessibility retesting means checking a reported barrier again after a change, in the same relevant page state, and recording whether the user can now complete the task. Use this checklist when a developer hands a fix to QA, when an agency reports progress to a client, or when a team reviews a release.

1. Save a baseline you can reproduce

Keep the original report, affected page, rule or criterion reference, element evidence, and reproduction steps. Record the build, browser, viewport and any relevant interaction state. A homepage scan cannot stand in for a checkout dialog that only appears after a particular action.

For repeated GatekeeperQA checks, use a named test set to keep the intended page list together. A test set records scope; it does not record every browser condition or interaction.

2. Confirm the fix is in the tested build

Check that the changed component is present. If a finding disappears because the component failed to load or was removed from the scan, that is not evidence that its accessibility was repaired. Note changes in page coverage, failed requests and incomplete checks before comparing counts.

3. Repeat the automated check on the same scope

Compare completed runs with matching pages and conditions. Separate newly detected findings, findings still detected, and findings no longer detected. Keep checks needing review separate from confirmed findings. A chart is a summary of this evidence, not a compliance percentage.

GatekeeperQA can group saved history by page and test-set revision. Its hosted scanner checks the initially loaded public page state. Protected pages and interactive states need a separate testing approach; the hosted scanner does not log into the site for you.

4. Test the interaction manually

Repeat the task that originally failed. For a button, check its visible text, keyboard focus, activation and announced name in the relevant assistive technology. Test related loading, error and confirmation states when they are part of the task. Record which checks you actually performed and which remain open.

Use the manual-evidence guide to write steps another team member can reproduce. Automated checks do not cover every accessibility requirement; W3C provides evaluation methodology guidance for planning scope and reporting results.

A small before-and-after example

Our preserved demo started with an unnamed native button and one critical automated finding. Adding visible “Checkout” text resulted in zero confirmed automated findings on the next run of that fixture. That establishes a narrow automated change, not a full accessibility pass.

See the actual code change and both demo reports. Keyboard and screen-reader checks are follow-up guidance there, not claimed completed results.

5. Give the team a useful retest record

Keep “no longer detected” distinct from “manually verified.” A developer can use the evidence to refine a fix, QA can reproduce it, and a lead or client can understand what is still outstanding.

Copy this retest note

Issue / component:
Baseline report and build:
Retest report and build:
Pages and conditions:
Coverage differences or scan errors:
Automated result:
Manual steps performed and observed result:
Checks still open:
Follow-up owner and issue:

Common questions

Does zero automated findings mean the website is accessible?

No. It means those automated checks found no confirmed findings in that tested scope. Missing coverage, unresolved checks and manual testing still matter.

Can I compare scans with different page lists?

You can review each result, but the overall counts are not a like-for-like progress measure. Keep a matching scope for retesting, and explain scope changes separately.

How can I share the result?

GatekeeperQA offers exports and optional read-only snapshots of saved reports. Review evidence before sharing: anyone with a snapshot link can view it until it expires or you revoke it. Read the sharing controls and retention limits.

Try the workflow

Explore the sample report, continue to the scanner, or run the CLI locally. Saved reports retain the latest ten runs for up to thirty days; download evidence you need to keep longer.