Whether it is typesetting the official gazette, an expert report or specialist administrative software: which requirements for accessible PDFs belong in the specification, how proof and acceptance work – and which wording you are better off leaving out.
A workable requirement for accessible PDFs has three parts: a clear technical benchmark (PDF/UA according to ISO 14289 plus the WCAG level AA success criteria as applied to documents by chapter 10 of EN 301 549), proof (a machine test report and documented manual checks) and acceptance with spot checks and an obligation to remedy defects. If the description of services (in German procurement: the Leistungsverzeichnis or Leistungsbeschreibung) only says “accessible”, you get documents whose accessibility is argued about afterwards – usually once they are already online.
Why this belongs in the description of services
Above the EU thresholds, Section 121(2) GWB (Gesetz gegen Wettbewerbsbeschränkungen, the German Act against Restraints of Competition, which contains Germany’s procurement law) requires that, for services intended for use by natural persons, the accessibility criteria for people with disabilities be taken into account except in duly justified cases. This transposes Article 42 of Directive 2014/24/EU. Section 31(5) VgV (Vergabeverordnung, the German Public Procurement Regulation) adds: where mandatory accessibility requirements arise from a legal act of the EU, the description of services must refer to them. Below the thresholds, budget law and the procurement law of the individual German states apply; you should check for your state whether and how something comparable is regulated there.
Irrespective of procurement law: whatever a public body commissions, pays for and provides on its website, it generally has to provide in accessible form as well (see BITV 2.0 for municipalities – BITV 2.0 being Germany’s federal accessibility ordinance for IT). If the requirement is missing from the contract, the rework becomes your effort – or a change order.
Which services are affected
- Typesetting and production: official gazette, brochures, reports, budgets (official gazettes, budgets).
- Expert reports and planning: specialist contributions, concepts and plans that are published as attachments.
- Forms: fillable PDF forms and form servers (PDF forms).
- Software that generates PDFs: council information system, specialist administrative software, printing of official notices and mail merges. Here, the tender determines every future document.
- Remediation of existing documents: services or tools that check and repair existing PDFs.
Building blocks for the specification
- Technical benchmark: “Delivered PDF documents comply with ISO 14289-1 (PDF/UA-1) or ISO 14289-2 (PDF/UA-2) and with the requirements of chapter 10 of EN 301 549 applicable to documents, WCAG level AA.” Whether you name WCAG 2.1 or 2.2 depends on the version of EN 301 549 you refer to (WCAG 2.2 and EN 301 549); why both parts of PDF/UA should be accepted is explained in PDF/UA-1 or PDF/UA-2?
- State minimum content requirements explicitly, because checking tools cannot assess them: logical reading order, heading hierarchy, alternative text for informative images (agreed with the responsible department), tables with header cells, a meaningful title, document language, bookmarks from a page count you specify, contrast according to WCAG 1.4.3, and for forms tooltips, tab order and recognisable mandatory fields.
- Source files: delivery of the editable source files (for example Word or the layout file) with paragraph styles and export settings set up. Otherwise every later correction has to be repaired after the fact all over again.
- Proof per document: a machine test report without errors – stating the checking tool, version and test profile – and a short record of the manual checks (reading order, alternative text, spot check with a screen reader).
- Acceptance and remedy: you reserve the right to carry out your own check; defects are remedied free of charge within a fixed period; a document only counts as accepted once the test report and the spot check pass.
- Timing: the accessible version is delivered together with the print version – not “promptly afterwards”.
You may name checking tools as examples. Under Section 31(6) VgV, however, references to specific products are only permitted by way of exception and must carry the addition “or equivalent”; it is safer to describe the check in terms of the standard and its rules. Why two tools can produce different results is explained in PAC and veraPDF.
What you should not require
- “100 % automatic” or “guaranteed compliant by software”: according to the Matterhorn Protocol, 47 of the 136 failure conditions of PDF/UA-1 generally require human judgement. An offer that promises this says more about the supplier than about the result.
- A green check result as the only acceptance criterion: a document can pass every machine check and still have meaningless alternative text or a wrong reading order.
- WCAG level AAA across the board: WCAG itself does not recommend requiring AAA as a general policy for entire sites, because not all AAA criteria can be met for every type of content.
- “BITV-compliant” without further detail: which version, which criteria, which proof? Without this information the requirement can hardly be verified.
- PDF/UA-2 exclusively: today this rules out many ways of producing documents, without users automatically benefiting.
Acceptance in practice
- Check every delivered document by machine – that is fast and documented.
- For a sample, listen to the first pages with a screen reader, plus at least one complex table and, if there is one, a form (how to test it yourself).
- Have the responsible department proofread alternative text for charts and plans.
- Copy test: select text and paste it – does readable text come out, including umlauts and special characters?
- Record the result and open points in writing; this is also your proof towards supervisory and monitoring bodies.
Common mistakes
- The requirement is only added after the contract has been awarded and leads to a change order.
- Only the print PDF has been agreed; the accessible version is not part of the scope of services.
- No test report required – or one without stating the tool and version.
- Acceptance without a spot check: defects only come to light through a complaint.
- Source files stay with the service provider; every correction costs money again.
- Specialist software is procured without asking whether it produces tagged PDFs.
How DokAudit helps
With DokAudit you can carry out acceptance of delivered documents yourself: the check runs with veraPDF and DokAudit’s own checks of the logical structure based on the Matterhorn Protocol, the test report is available as HTML and PDF and states explicitly what a human still has to assess. If a publisher or service provider delivers regularly, the check can be built into the workflow via the REST API and webhooks; in many cases defects can be fixed automatically straight away. And if you are tendering for a PDF remediation tool yourself: word it product-neutrally and measurably – we are happy to be measured against clear criteria.
Sources:
As of: 10/2026. This article provides a general overview and is not legal advice. The statutory and standards texts in force are authoritative; in individual cases the law of a German state may differ.