State page count, languages, source application and difficult content such as tables, forms or mathematics. Explain whether the file will be published, archived or used in a particular service. Separate requirements from preferences.
Specify the target standard version and any legal requirements after assessing their applicability. Accessible under current rules is too vague as the only technical acceptance criterion.
“Accessible PDF” leaves important questions unanswered. Identify the file and edition, the standard versions to apply and the content types to inspect. A legally required level forms part of the brief’s basis; any higher contractual requirements should be explicit.
Request a small representative sample before commissioning a large batch. Include a difficult spread and a reader task, such as finding eligibility conditions through headings and identifying February’s amount with its unit. This reveals more about the method than a screenshot of green checks.
Decide how exceptions are handled. A supplier can repair tagging but may need the document owner to resolve an ambiguous chart, an illegible number or a missing instruction. Identify the decision-maker and which edits require substantive approval. This prevents a technical repair becoming an unnoticed editorial change.
Repair the named 24-page Swedish report. Preserve text, figures and intended layout. Identify changes requiring the document owner’s decision. Assess against the agreed PDF/UA version and applicable WCAG criteria. Deliver the file, automated report, manual findings and practical test record.
Insert exact versions before commissioning. This example supports the discussion; it is not a complete legal specification.
First verify identity: do the reports refer to the delivered file? Filenames can be reused; a SHA-256 hash identifies the file’s byte content. If the supplier edits it after checking, evidence must be linked to the new version. Request clear version names even where hashes are used.
Then read the evidence as a basis for a decision. Which checks ran, using which tools and versions? What received manual assessment? Which reading tasks were tried, in which environment? “Screen-reader tested” alone does not show whether anyone examined tables or merely opened page one.
Distinguish a passed check from delivery acceptance. The document owner needs to see outstanding defects, their reader impact and the agreed remedy. A blocking problem should not disappear beneath an overall pass label. For batches, identify fully reviewed files and explain any sampling.
Store the final file and evidence where the next responsible person can find them. Replacing a cover or merging an appendix later requires assessment of potentially affected parts. The handover record should support that work as well as close the purchase.
| Evidence | Question it answers |
|---|---|
| Filename and SHA-256 | Which file does the result cover? |
| Tool, version and profile | What was checked automatically? |
| Manual review | How were meaning and content assessed? |
| Practical test | What could the tester actually do? |
| Remaining issues and decision | What remains, and who accepts or rejects the delivery? |
An editor may accidentally damage structure during the next export. Agree whether the template will be improved, who performs recurring checks and which changes trigger reassessment. This reduces the chance of paying for the same repair again.
Sources
- ISO 14289-1:2014 (PDF/UA-1)ISO
- Web Content Accessibility Guidelines (WCAG) 2.2W3C
- EN 301 549 V4.1.1 (2026-09)ETSI
Examples are our own unless stated otherwise. These guides distinguish legal requirements, standards and practical advice. Passing an automated check is not a complete assessment of document accessibility.