An Accessibility Conformance Report summarizes how a product supports applicable accessibility criteria. It is not a list of bugs pasted into a table. Each criterion row needs a conformance value and an explanation that reflects the product, evaluated scope, active findings, resolved issues, and applicability decisions. The strongest workflow builds those rows from a maintained WCAG project and preserves the approved result as a snapshot.
The problem this guide solves
When report authors work directly in a document, findings and conformance can drift apart. A bug may be fixed in the tracker but remain in the ACR, or a new critical issue may never reach the document. Criteria introduced in a later WCAG version may be marked Not Applicable in an older report even though they should not appear at all. Generic Supports remarks can also claim more than the recorded assessment evidence supports.
Understand the standard and the boundary
The ITI VPAT templates provide structured tables for standards such as WCAG, and the completed document is commonly called an ACR. WCAG version and level determine which success criteria belong in scope. Conformance values such as Supports, Partially Supports, Does Not Support, Not Applicable, and Not Evaluated should be resolved consistently, with professional review of every exception and manual override.
Read the official ITI VPAT resources
Who this workflow helps
- Accessibility auditors producing client ACRs.
- Vendors answering procurement and customer questions.
- Product teams maintaining accessibility statements and roadmaps.
- Students practicing criterion-level conformance analysis.
A professional workflow
A dependable assessment does not begin with a report button. It begins with a clear question, defined scope, the correct standard, suitable test methods, and a record that another authorized reviewer can follow. The sequence below is designed to preserve that chain. Adapt its depth to the engagement, but do not remove the review decisions merely to make the process appear faster.
- Select the report WCAG version and A, AA, or AAA target that matches the work performed.
- Confirm every included criterion and exclude criteria from newer versions or higher levels.
- Group project findings by canonical criterion and consider their current status and validation.
- Apply deterministic conformance rules before drafting explanatory language.
- Write criterion-specific remarks from the actual issue pattern or supported behavior.
- Review Not Applicable, Not Evaluated, manual overrides, metadata, methods, contacts, and disclaimer.
- Render the matching DOCX template and inspect the complete file.
What to record
Record enough information to support reproduction, assignment, remediation, validation, and reporting. Each field should have one clear purpose. Keep identifiers and quoted evidence exact, distinguish observations from recommendations, and avoid collecting secrets or personal information that the work does not require. A smaller complete record is more useful than a large collection of disconnected text and files.
- Project and product metadata, tested pages or flows, and methods.
- Canonical WCAG success criterion, title, level, and reference.
- Related finding summaries, descriptions, affected elements, actual results, severity, and status.
- Rule-resolved conformance and reviewer-approved remarks.
- Applicability reason, override indicator, warning, and drafting source.
- Template path, report date, creator, and immutable export snapshot.
How voiqq supports the work
voiqq uses one project and finding foundation across Programs while each Library controls its own requirements, fields, metrics, mapping, automation boundary, and report rules. That means teams can reuse assignments, comments, evidence, validation, history, permissions, imports, exports, and recovery without pretending that every standard reaches the same kind of conclusion.
voiqq implements one VPAT engine with separate configuration for each WCAG Library. The configuration controls template path, allowed levels, criterion inclusion, immutable special cases, report language, filename, and cell mapping. Conformance is rule-based rather than AI-decided. AI can draft product descriptions and remarks through a provider fallback chain, while a criterion-specific deterministic library keeps generation available when every AI provider fails.
Quality checks before sharing
- Verify that all active critical findings affect conformance as intended.
- Ensure resolved or verified-fixed findings do not reduce conformance.
- Do not include unmapped findings silently.
- Read remarks for unsupported features, certification claims, technical selectors, and repetitive filler.
- Confirm logo, contact headings, evaluation methods, fonts, template formatting, and Word compatibility.
Before distribution, ask a second question beyond whether the file generated: can the intended reader understand the scope, trace important statements to project evidence, distinguish active and resolved work, and see the limits of the conclusion? Review permissions and attachments as carefully as report wording. Preserve an approved snapshot when the deliverable must remain stable after the live project changes.
A practical next step
Generate one draft ACR early in the engagement. The preview will reveal missing mappings, vague descriptions, incomplete product metadata, and untested criteria while there is still time to correct the project. Repeat the final export only after remediation and validation data is current.
Treat the first result as a review draft. Check it with the people who perform the work and the people who receive the outcome. Their questions will reveal missing context, confusing terminology, weak permissions, and report assumptions sooner than another decorative dashboard will. Improve the project model, then repeat the same disciplined workflow.