One PDF, two checking tools, two results: what veraPDF and PAC each check, where the differences come from, how to assess them – and why neither of them replaces testing by people.
veraPDF and PAC do not measure exactly the same thing. veraPDF checks the machine-checkable rules of PDF/UA, each rule referring to a section of the standard ISO 14289. PAC also checks PDF/UA, plus WCAG-related points such as colour contrast, and offers views for visual inspection. Differing results are therefore normal, and often both tools are right. Neither replaces testing by people: according to the Matterhorn Protocol, 47 of the 136 failure conditions of PDF/UA-1 generally require human judgement.
veraPDF in brief
- What it is: an open-source validator from the veraPDF Consortium which, by its own account, covers all parts of PDF/A and PDF/UA.
- Rule set: the checking rules for PDF/UA-1 and PDF/UA-2 are publicly documented. Each rule has a number made up of the section of the standard and a test number – for example 7.18.1-3 (form field without a tooltip) or 7.21.7-1 (character without a Unicode mapping).
- Result: the number of failed checks per rule. Counting is per checked object – a single systematic problem can therefore produce thousands of hits.
- What it does not check: colour contrast and anything that requires a judgement about content.
PAC in brief
- What it is: the free PDF Accessibility Checker, which has existed since 2010 and, according to the publisher’s website, is funded by the German Federal Ministry of Labour and Social Affairs.
- Scope: checks for PDF/UA and WCAG, plus a screen reader preview and a structure preview that let sighted people follow what is read aloud. The result comes as an overview or a detailed report.
- New: according to the publisher, the current version, PAC 2026, adds AI-assisted checks intended to reduce manual checking steps.
- Errors and warnings: PAC distinguishes between errors and warnings. What the most common messages mean is explained in The 10 most common PAC errors – explained.
Where the differences come from
- Different scope: veraPDF sticks to the PDF/UA rules. PAC also checks WCAG points. A document can be error-free in veraPDF and fail in PAC because of insufficient contrast.
- Separate implementations of the same standard: both tools translate the requirements into checking code independently of each other. In borderline cases the assessment is therefore not always the same.
- Counting method: veraPDF counts failed checks per object, PAC groups findings by checkpoint. ‘2,000 errors’ in one tool and ‘3 errors’ in the other can be the same problem.
- Error, warning, notice: not every message is a breach of the standard. Warnings point to places a person should look at.
- Profile and version: was the file checked against PDF/UA-1 or PDF/UA-2? With which program version? Rules are refined and bugs fixed – an older report cannot simply be compared with a new one.
- Additional heuristics: some tools go beyond the standard and check for anomalies in the logical structure, such as skipped heading levels or suspicious use of figure tags. Such messages are hints, not verdicts.
An example
If an embedded font lacks a Unicode mapping, veraPDF reports rule 7.21.7-1 for every affected character – in a document of several pages that quickly adds up to hundreds or thousands of failed checks. In an overview grouped by checkpoint, the same problem appears as one entry with a count. Both reports describe the same error with the same cause, and a single repair – adding the mapping – removes all hits at once (Case study: fonts without Unicode). The number of errors therefore says little about the effort involved; what matters is how many different causes lie behind them.
How to deal with differing results
- Take errors from both tools seriously. A rule violation reported by veraPDF is a clear breach of a machine-checkable requirement.
- Read and assess warnings instead of reflexively ‘repairing them away’.
- Re-measure contrast findings for text on photos or gradients by hand (Colour contrast in PDFs).
- Record in the test report which tool, which version and which profile were used.
- For contracts, agree in advance which check counts as acceptance (Tendering for accessible PDFs).
What none of the tools can do
- judge whether an alt text adequately replaces the image in its context,
- decide whether the reading order makes sense in terms of content,
- check whether headings and link texts are understandable,
- recognise whether information is conveyed by colour alone,
- establish whether text produced by optical character recognition is correct in content.
That takes people – with a screen reader, a keyboard and expertise. How to do it without specialist knowledge is shown in Test it yourself: the 5 quick checks.
Common mistakes
- ‘PAC is green, so the document is accessible.’
- The number of errors is compared instead of their type.
- A report from an outdated program version is used as evidence.
- The PDF/UA identifier is set because one tool shows no errors while the other still reports violations.
- Content is marked as an artefact to make messages disappear – which also makes it disappear for screen reader users.
How DokAudit helps
DokAudit uses veraPDF for checking against the standard and adds its own checks of the logical structure based on the Matterhorn Protocol as well as its own contrast measurement, because veraPDF does not check contrast. Every finding is explained in German, with reference to PDF/UA and the WCAG success criterion; anything only a person can judge is explicitly named in the report. There is nothing against an additional check with PAC – in the case study on SEPA forms, the PAC report also showed no more errors after the automatic repair.
Sources:
As of: 10/2026. This article gives a general overview and is not legal advice. The legal and standards texts in force are authoritative; in individual cases, the law of the German states (Länder) may differ.