Reports, minutes and attachments: why the attachments in particular are the problem, how many documents per meeting cycle can be prepared automatically, and when a connection via API is worthwhile.
Meeting documents become accessible when three things come together: reports are created from accessible document templates, every PDF is automatically checked and repaired before publication, and attachments – especially scans and documents from third parties – are handled separately. The public part of a council information system (Ratsinformationssystem, RIS – the software German municipalities use to publish agendas, reports, resolutions and minutes of council and committee meetings) is as a rule part of the municipality’s web presence, even if a service provider operates it. The reports, minutes and attachments provided there are therefore documents to which the accessibility requirements apply.
Three document types, three problems
- Reports and draft resolutions: they are usually created from a template in the RIS or in Word. Their quality depends almost entirely on that template: are the subject, the statement of facts and the proposed resolution marked up as headings? Does the table ‘Financial implications’ have a header row? Is a document title set – or does ‘Vorlage_2026_0815.pdf’ appear?
- Minutes: long documents in which people look for one specific agenda item. Without a heading for each agenda item and without bookmarks, screen reader users have to listen through the entire minutes. Voting results and attendance lists are often in tables.
- Attachments: expert reports, plans, statements, presentations, signed letters. They often make up the largest part of the documents, come from many sources and are the most likely to be scanned or untagged.
Lever 1: the source documents
Whatever is set up correctly in the template does not have to be repaired later. A checklist for the document template for meeting reports:
- Styles for the subject, subheadings and proposed resolution instead of manual bold formatting.
- Tables with a real header row, without merged cells and without tables used as a layout grid.
- Header area (report number, lead department, sequence of committees) as normal text or a simple table, not in text boxes.
- Document title taken from the subject, document language set to German.
- PDF generation with tags – check whether your RIS’s PDF output produces tagged PDFs, and if in doubt ask the vendor.
The details for Word are in the 10-point guide.
Lever 2: the attachments
- External expert reports and plans: specify accessibility as a performance requirement when commissioning them – this is cheaper than any rework.
- Scans: text recognition (OCR) followed by structure; limits and alternatives are described in Scanned archive documents.
- Plans and maps: an alt text with the key message, and the relevant details in the text of the report.
- Presentations and spreadsheets: export with tags from the original program instead of using ‘Print to PDF’; large tables according to the rules in Budgets and large tables.
Lever 3: bulk processing
A meeting cycle with specialist committees and the council quickly produces dozens of documents, and the statutory notice periods for convening meetings leave little leeway. Fixing individual PDFs by hand does not scale. What works is a fixed process: all documents for a meeting are processed together, automatically checked and repaired; only the documents that cannot be repaired safely go to a person. The order is important – prepare first, then publish. Anyone who repairs afterwards has to replace every file in the RIS, and until then the inaccessible version is online.
Connection via API
The least effort arises when the RIS itself triggers the check: when a report is released, the PDF is passed to a checking interface, the accessible version comes back automatically and replaces the original before publication. Whether and how this can be implemented depends on which interfaces your RIS vendor provides. If there are none, the public pages of the RIS can at least be monitored regularly so that new inaccessible PDFs are noticed (see Keeping your website’s PDFs under control).
Caution with signed documents
Repairs to the structure do not change the printed appearance, but they do change the file. If a set of minutes is electronically signed, any subsequent change invalidates the signature. For such documents there are two clean approaches: create the accessible version before signing, or provide an accessible reading version alongside the signed original.
Common mistakes
- The file name appears as the title (‘TOP_7_Anlage_3.pdf’, i.e. agenda item 7, attachment 3).
- Attachments are scans without text recognition.
- Minutes have no heading for each agenda item and no bookmarks.
- Repaired versions stay in the specialist department while the original remains in the RIS.
- Signed documents are overwritten and lose their signature.
- Non-public documents are forgotten – yet council members with visual impairments also need accessible reports.
How DokAudit helps
In the document hub you upload up to 50 PDF or Word files at once and assign them to a project, for example one per committee. The fully automatic mode applies all safe repairs – tags, headings, tables with header cells, title, language, bookmarks, OCR for scans – and checks again with veraPDF and its own checks of the logical structure. Documents for which this does not succeed safely are flagged as ‘Needs attention’ instead of being silently made worse. Via the REST API and webhooks, DokAudit can be connected to a RIS (API and integration); the data is stored in an ISO 27001-certified data centre in Germany. Questions of content, such as the alt texts for plans, remain with the specialist departments.
Sources:
As of: 09/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.