An accessibility team may test a product in English, receive evidence from a Dutch client, and need to deliver an Accessibility Conformance Report to a German procurement group. The difficult part is not translating the word Supports. The difficult part is keeping every success criterion, finding state, explanation, and limitation consistent while the report changes language. A disconnected copy-and-translate process makes that consistency hard to prove.
Why manual document translation breaks traceability
Traditional VPAT preparation often begins after testing has finished. Findings sit in a spreadsheet, retest notes live in email, product scope is stored in a proposal, and someone opens a blank VPAT under deadline. If that document must support several languages, each copy develops its own wording and sometimes its own conclusions. A fixed finding can remain described as open. A WCAG 2.2 criterion can enter a WCAG 2.1 report. A careful limitation can become an absolute compliance claim.
The safer approach is to keep one canonical Accessibility project and treat each report as a reviewed snapshot. The project holds normal findings, mappings, status, validation, pages, evidence, methods, and ownership. The report configuration chooses the WCAG version, target level, language, and template. This separation lets an auditor correct the source once and generate another reviewed deliverable without copying the audit into a second system.
Keep WCAG boundaries exact
WCAG success criteria are versioned and levelled. A WCAG 2.0 report cannot include criteria introduced in 2.1 or 2.2. A WCAG 2.1 report includes the applicable 2.0 and 2.1 criteria but not 2.2 additions. Level AA includes A and AA, while Level AAA includes A, AA, and AAA. Criteria outside the chosen version or level are excluded. They should not be labelled Not Applicable merely because they are newer or higher.
Not Applicable has a narrower meaning: the criterion belongs to the selected report scope but does not apply to the evaluated product. Not Evaluated means the project did not evaluate it. Those decisions need reviewer judgment and a defensible explanation. Translation cannot make either decision, and an AI drafting provider must never be allowed to choose between them.
Make the Accessibility project report-ready
Before opening the generator, review the project as if another auditor will inherit it tomorrow. Every finding that should affect conformance needs an accurate WCAG mapping. Status and validation must distinguish active issues from fixes that passed retesting. Summary, description, affected elements, actual result, severity, and page information should describe the observed barrier without raw selector clutter. Unmapped findings remain visible as warnings instead of being forced into an unrelated criterion.
- Confirm the Accessibility Library, WCAG version, and project target level.
- Resolve duplicate findings and verify fixed or closed records with current evidence.
- Map each report-relevant issue to the most accurate success criterion.
- Review criteria recorded as Not Evaluated or Not Applicable.
- Check product name, vendor, version, pages, flows, methods, dates, contacts, and disclaimer.
- Prepare a clear product logo and confirm permission to use it in the report.
Generate the first reviewed language
Open the project and choose Generate VPAT / ACR. Select the report version and Target conformance level, then choose Report language. Preliminary Review collects the product identity, description, contacts, methods, date, notes, disclaimer, and required logo. Read these fields instead of accepting polished prose because it sounds confident. Product descriptions should be supported by the project name, URLs, tested areas, scope, and known product facts.
Conformance Preview separates deterministic results from editable report prose. Open critical or blocking findings can produce Does Not Support. Other active findings can produce Partially Supports. Criteria with no active mapped findings can produce Supports, while reviewed scope decisions produce Not Applicable or Not Evaluated. A manual override changes only the snapshot. It does not quietly rewrite the finding register.
Move from English to the recipient language
voiqq supports English, Dutch, French, German, Spanish, Italian, and Polish professional reports from Pro upward. For each non-English export, the engine selects the language-specific template that also matches WCAG 2.0, 2.1, or 2.2 and Level A, AA, or AAA. It fills that copy rather than converting an English DOCX into generic HTML. The original template remains untouched.
Known report labels and deterministic remarks can be localized safely, but source evidence deserves restraint. Keep success criterion numbers, URLs, product names, company names, code, selectors, and quoted observations exact unless an authorized reviewer approves a translation. If the project contains a Dutch client statement, generating a French report does not prove that statement has been professionally translated.
Write remarks that sound like an auditor
Good remarks explain product behavior in relation to the criterion. They avoid bug IDs, class names, raw CSS selectors, repetitive tracker language, and phrases that add no meaning. When several findings map to one criterion, the explanation should combine the shared user impact without hiding distinct barriers. When one finding maps to several criteria, each row should describe the part relevant to that criterion rather than repeating the same paragraph.
AI may help draft this language from approved project facts, but the prompt must hold the conformance value fixed and prohibit invention, certification, legal claims, and severity exaggeration. If providers are unavailable, a criterion-aware deterministic library should still create usable prose. In both cases, a fluent accessibility professional edits the report before release.
Inspect the DOCX as a client will receive it
Download the file and open it in Microsoft Word. Confirm that the product logo is sharp, the product name and optional version appear as normal text, contacts follow one consistent pattern, evaluation-method headings use the intended font and size, conformance values are centered and bold, and remarks use consistent typography. Test links and review page breaks. A valid ZIP package that opens only in an online editor is not an acceptable Word deliverable.
- Compare criterion counts with the selected WCAG version and level.
- Confirm Parsing follows the configured version-specific treatment.
- Read every Supports remark for criterion-specific meaning.
- Check that active and resolved findings influence conformance correctly.
- Review translated specialist terminology with a fluent auditor.
- Keep the approved export snapshot with the project record.
One audit record, several defensible deliverables
Students can learn how findings connect to conformance. Independent auditors can reduce document assembly time. Accessibility teams can maintain consistent language across products. Schools, public agencies, procurement teams, and international companies can receive a report they can read without losing the underlying WCAG traceability. The gain comes from disciplined reuse of reviewed data, not from pretending that document generation replaces testing.
Start an Accessibility project