Retest Versions (v1.0 → v1.1)
A retest version is a minor version bump. Use it when a development team has addressed your findings and you need to verify that fixes are correct. Labrador copies your entire audit forward so you can check each finding without re-documenting anything from scratch.1
Open the Audit version bar
Open your project and locate the Audit version bar near the top of the project view. It shows the version you are currently working in and contains the version controls.
2
Create a retest version
Click Version actions and select Create retest version. Labrador creates a new minor version, for example, v1.0 becomes v1.1.
3
Review what was carried forward
Labrador copies all your pages, all criterion statuses, all notes, and every logged issue into the new version. Carried-forward issues are labelled Carried forward from their source version so you can identify them at a glance.
4
Retest each finding
Work through each carried-forward issue. Retest the affected element on the live site and update the issue’s remediation status as appropriate. When a fix is verified, set the issue status to Closed.
When every carried-forward issue on a criterion is closed, Labrador automatically updates the criterion’s status to reflect the resolved state, you do not need to update it manually. If you reopen a closed issue, the criterion status reverts accordingly. Your original version (v1.0) is never modified by the retest process.
New Audit Versions (v1.x → v2.0)
A new audit version is a major version bump. Use it whenever you need a fresh, standalone evaluation rather than a targeted retest of previous findings. That covers two common situations:- Scheduled re-evaluations. Regular cadence testing, quarterly, twice-yearly, or annual accessibility check-ins on a stable product, should be captured as a new major version. This keeps each round of testing cleanly separated in your history, which is often exactly what compliance programmes, procurement conversations, and internal reporting expect.
- Significant product changes. A redesign, platform migration, or major feature release also warrants a new major version, because the previous audit no longer reflects what is on the site.
Keep Pages
Copies your page, component, and user journey list, including names, URLs, and any testing environment details, into the new version. Criterion statuses and issues start completely fresh.Use this when: you are running a scheduled re-evaluation on a stable scope, or the site has changed but the same pages, components, and journeys still apply.
Blank Audit
Creates a completely empty new version of the project. Nothing is carried over, no items, no statuses, no issues.Use this when: the site has been rebuilt from the ground up, the scope has changed significantly, or you want a clean slate with no reference to previous findings.
Switching Between Versions
Use the version dropdown in the Audit version bar to switch between any version of your project. When you are viewing a version that is not the latest, a Viewing vX badge appears in the interface as a reminder that you are looking at historical data rather than the current working version.Switching versions is read-only for older versions, you can review and export findings from any version, but edits are only possible in the current working version. This ensures your audit history is preserved accurately.
Deleting a Version
To remove a version you no longer need, click Version actions and select Delete v…. A confirmation dialog appears, spelling out exactly what will be removed before anything is deleted. After deletion, you are moved to another available version automatically.Recommended Workflow
This versioning model maps naturally to a typical client engagement cycle. Following this pattern keeps your findings organised and makes it easy to demonstrate remediation progress to stakeholders.1
Initial audit, v1.0
Run your full accessibility audit. Evaluate all pages and components, log every issue you find, and assign severity levels and remediation statuses. When testing is complete, export the report and share it with the development team.
2
Development team implements fixes
The development team works through the remediation backlog. As they fix issues, they update remediation statuses to In Progress and Fixed for Retesting, either directly in Labrador (if they have access) or by communicating with you so you can update the statuses on their behalf.
3
Retest, v1.1
Once a meaningful batch of fixes is ready for verification, create a retest version. Work through the carried-forward issues, test each fix on the updated site, and set verified issues to Closed. Export an updated report showing the improved conformance state.
4
Repeat retests as needed
If fixes are incomplete or new issues emerge during the retest, create additional retest versions as needed (v1.2, v1.3, and so on). Each version captures the state of the audit at that point in time.
5
Scheduled re-evaluation or major redesign, v2.0
Start a new major audit version whenever you need a fresh evaluation. This covers scheduled cadence testing (for example, a quarterly or annual re-audit of a stable product) as well as significant redesigns and rebuilds. Choose Keep pages if the scope is largely unchanged and you just want fresh results, or Blank audit if you are starting from scratch. Your entire previous audit history remains accessible in the earlier versions.