WCAG 2.2 Demo SuiteStep 5 — Report the findings
The report is the deliverable. It has two jobs: to say honestly what you found, and to let somebody else check your work.
5a. Document the outcome
A WCAG-EM report must contain all of this. Omitting the sample is the most common failing, and it is the omission that makes a report unverifiable.
- The scope from Step 1 — the site definition, the conformance target, the baseline, and anything excluded.
- The date of the evaluation and who performed it.
- The sample from Step 3, listed as URLs, with the reason each page was chosen. This is what makes the audit reproducible.
- The result for each criterion in scope: pass, fail, or not applicable.
- The detailed findings from Step 4, with evidence and suggested fixes.
- The tools and methods used.
5b. Make a conformance claim — or do not
Be careful and be literal. A conformance claim is a formal statement, and overstating it is both dishonest and a legal exposure.
| Say | Not | Why |
|---|---|---|
| "The 14 pages evaluated on 9 September 2026 did not meet WCAG 2.2 Level AA. 11 criteria failed." | "The site is 87% accessible." | There is no percentage in WCAG. Conformance is per page and binary. |
| "No failures were found in the sample. This is not a claim about pages outside it." | "The site conforms to WCAG 2.2 AA." | A sample cannot prove conformance of pages you did not open. |
| "Partially conformant: the site meets Level A but not Level AA." | "Mostly accessible." | Name the level. "Mostly" means nothing. |
Note the asymmetry, which students find counter-intuitive: sampling can disprove conformance conclusively — one failure is enough — but it can never prove it. This is why an honest report says what was evaluated and when, not that the site is accessible.
5c. Provide a performance score — carefully
WCAG-EM permits an optional score, and warns against it. If a client insists, report counts rather than a percentage: how many criteria failed, on how many pages, at what severity. A single number invites the wrong conversation — teams optimise the number instead of fixing the barriers.
Accessibility statements and VPATs
| Document | Audience | Purpose |
|---|---|---|
| Evaluation report | The team that will fix it | What is broken, where, and how to fix it |
| Accessibility statement | Users of the site | What is and is not accessible, what to do if you hit a barrier, and how to complain. Often legally required and published on the site. |
| VPAT / ACR | Procurement | A standard-format declaration of how a product conforms, criterion by criterion, used when buying software |
A VPAT is the blank template; once you fill it in it becomes an ACR — an Accessibility Conformance Report. Each criterion gets one of "Supports", "Partially Supports", "Does Not Support" or "Not Applicable", with remarks. "Partially Supports" is not a WCAG conformance category — it exists so a procurement reader can see nuance — so never let a VPAT's language leak into a conformance claim.
Writing findings people will act on
- Lead with the user impact, not the criterion number. "A blind customer cannot complete checkout" gets fixed; "4.1.2 failure" gets triaged.
- Group by cause, not by page. One component fix usually closes dozens of instances.
- Give a concrete fix, with code where you can.
- Note what is already good. A report that is only bad news gets read once.
- Separate the conformance result from the priority list. They answer different questions.