Method
The Suretto Method
The principles behind every report we issue and every pull request we open. They are written down so that you can hold us to them.
1. Proof
How we decide what a report may claim.
1.1 The writer never grades.
The system that drafts a fix is never the one that marks it verified.
A check run by the author of a change tends to confirm what the author meant to do.
Our verifier receives the finished change and nothing else: not the fixer’s instructions, not its reasoning. It tests the rendered result with automated rules, recorded screen-reader runs, keyboard-only runs and contrast calculations from browser-derived colours. Independence here means separate systems within Suretto, not an external certification.
1.2 Every claim carries its artefact.
Each result in a report links to the recording, data table or annotated screenshot that shows it.
A pass without its evidence is an opinion.
With the artefact attached, an auditor, a buyer’s reviewer or your own team can check the claim without taking our word for it. A result with no artefact does not go in the report.
1.3 Judgement goes to a person.
Where a criterion needs judgement, a named reviewer decides, and the decision is recorded.
Whether alt text is meaningful, or an error message is clear, cannot be settled by a rule.
Those items go to a reviewer with the evidence in front of them, from your team or ours. The decision and the reasoning behind it stay in the report.
1.5 Reports are dated and reissued, never edited.
Each report states its date and the commit it was tested against. When the product changes, we issue a new report.
An edited report leaves no trace of what it said before. A reissued one leaves the earlier version intact, so anyone can see what was true on which date.
Reports are generated from the evidence store, which is what makes a reissue for any date possible.
1.6 We do not certify legal compliance.
We document how the assessed scope supports WCAG 2.2 A/AA, including failures, exclusions and untested areas. We do not certify that it complies with any law.
Laws are interpreted by courts and regulators, and no vendor can certify the outcome.
A badge or guarantee that claims otherwise draws the scrutiny it promises to prevent. What we stand behind is the evidence.
2. Working with you
How the work reaches your product.
2.1 Fixes live in your code.
We change your source code, not the page your visitors load.
A script that patches the page at runtime leaves the defect in the code and makes you depend on the script.
A fix in the code stays fixed if you stop working with us, and your team can read every line of it.
2.2 Small pull requests.
One defect class per pull request, each citing the criterion it addresses.
Small changes are quicker to review and safer to merge.
Each pull request describes the defect, the criterion and the verification that passed after the change. Your team reviews and merges every one; we merge nothing for you.
2.3 Read-only to start.
An audit and drafted fixes need read access to your repository and nothing more.
Write access is optional, and limited to opening pull requests. You grant access from your side and can revoke it at any time.
We work on a staging copy with test accounts, so no recording contains a real customer’s data.
2.4 Follow-up checks have a defined scope.
A report describes one assessed version. Monitoring repeats an agreed automated inventory at the frequency in your plan.
New features and content can introduce barriers. Automated monitoring and periodic human reassessment serve different purposes.
Automated results carry their test date. Human reviews, new journeys and ACR updates are separately scoped; earlier evidence is not silently marked current.
See the method in a finished report.
The sample report shows each principle at work on a fictional store: the artefact behind every result, the flags left in view, the reviewer's decisions and the date.
The process step by step is on how it works. The systems behind it are on the technology page.