01
Scan
Start with a real page.
Enter your public website URL. Save your website in a private workspace to keep its findings and repair history. Scan coverage belongs with the results.
A scan is a point-in-time check, not a compliance certificate.
How it works
From finding
to checked fix.
Six connected steps. Clear evidence at every stage.
Start with a scan02
Diagnose
Understand what needs attention.
Review the affected page and element, the accessibility rule, the likely user impact and the next supported action. Separate source repair candidates from issues needing human review.
An automated finding does not explain every barrier in a user journey.
03
Fix
Review the source change.
Select the branch and supported source file. Confirm the exact target and any meaningful text. Inspect the diff, then download the handoff or explicitly authorize a repository change.
A proposal is not an applied fix. Ambiguous source mapping stays under review.
04
Verify
Check what people actually receive.
Deploy the reviewed change through your website’s normal release process. Verification checks the stored page, selected element and expected value. Failed or incomplete checks remain visible.
A merged pull request is not proof of a deployed or accessible experience.
05
Document
Keep a factual record.
Download findings and remediation evidence. Keep the source location, original file identity, changed value, live verification result and rollback instructions together.
Reports describe tested scope and results. They do not certify legal compliance.
06
Monitor
Watch for new barriers.
Use recurring checks to compare consistent page coverage over time. Review new or returning findings and failed checks rather than assuming that missing scan data means an issue is resolved.
Monitoring requires a configured schedule. Its status belongs in the workspace.
Make the next step clear.
Review your website’s findings and follow the evidence through source review and verification.