Barrierefreie PDF-Rechnungen: was das BFSG verlangt und was dompdf nicht kann

Für PDF-Dateien gilt nicht die WCAG direkt, sondern Kapitel 10 der EN 301 549 für Nicht-Web-Dokumente, und in der Praxis heißt das PDF/UA nach ISO 14289: ein getaggtes PDF mit ausgezeichneten Überschriften, Tabellen und Listen, einem Dokumenttitel, gesetzter Sprache und definierter Lesereihenfolge. Genau das erzeugen die üblichen Shop-Systeme nicht.

Warum die Rechnung überhaupt betroffen sein kann

Das BFSG verpflichtet Anbieter bestimmter Dienstleistungen gegenüber Verbraucher:innen. Eine Rechnung, die Teil dieser Dienstleistung ist und über Ihren Shop bereitgestellt wird, gehört damit zum Leistungsumfang und nicht in eine Grauzone daneben. Gerichtlich durchentschieden ist die Frage bislang nicht, und wer etwas anderes behauptet, überdehnt die Quellenlage. Praktisch relevant ist sie trotzdem, weil die Marktüberwachungsstelle der Länder vorrangig auf Beschwerden reagiert und eine nicht lesbare Rechnung ein naheliegender Beschwerdegrund ist.

Frei bleiben Dienstleistungen von Kleinstunternehmen mit weniger als 10 Beschäftigten und höchstens 2 Millionen Euro Jahresumsatz oder Bilanzsumme. Diese Grenze zuerst prüfen, bevor Sie Aufwand einplanen.

Was ein Prüftool bei PDFs tatsächlich beanstandet

dompdf, der Standardweg in vielen PHP-Shops, erzeugt kein Tagging. wkhtmltopdf ebenfalls nicht. Das ist keine Konfigurationsfrage und lässt sich nicht per CSS oder Template nachrüsten: was der Generator nicht schreibt, steht nicht in der Datei.

Drei Wege, in dieser Reihenfolge sinnvoll

1. Information zusätzlich barrierefrei bereitstellen: die Rechnungsdaten als HTML-Ansicht im Kundenkonto. Zugänglich sein muss die Information, nicht zwingend genau diese Datei. Für viele Shops ist das der schnellste tragfähige Schritt.
2. Im PDF das Minimum setzen, das der vorhandene Generator hergibt: Dokumenttitel, Sprache, lineare Struktur ohne Layout-Tabellen. Damit bestehen Sie kein PDF/UA, fallen aber nicht mehr bei den einfachsten Punkten durch.
3. Wenn es getaggt sein muss, an der Engine ansetzen: ein Renderer, der PDF/UA erzeugt, oder ein Nachbearbeitungsschritt in der Pipeline. Das ist ein eigenes Projekt mit Test- und Abnahmeaufwand, kein Template-Fix.

Prüfen, ohne sich selbst zu täuschen

Automatisierte Prüfungen erfassen bei Dokumenten wie im Web nur einen Teil der Kriterien. In unserer eigenen Erhebung von 520 EU-Online-Shops erfüllten 92 Prozent die WCAG 2.1 AA nicht, häufigster Einzelbefund war zu geringer Kontrast mit 72 Prozent; die Methode dort war eine automatisierte Prüfung mit axe-core, die nach gängigem Konsens nur 30 bis 40 Prozent der nötigen Prüfschritte abdeckt. Ein grüner Automatik-Report ist deshalb bei PDFs besonders wenig wert. Entscheidend sind Tag-Baum und Lesereihenfolge, und die muss ein Mensch ansehen.

1. Tag-Baum öffnen und prüfen, ob Überschriften, Tabellen und Listen als solche existieren.
2. Vorlesen lassen und der Reihenfolge folgen: kommt die Summe nach den Positionen oder irgendwo dazwischen?
3. Dokumenttitel und Sprache in den Eigenschaften kontrollieren.
4. Datei markieren und Text kopieren: kommt zusammenhängender Text heraus oder Bruchstücke?

Dieser Artikel ist keine Rechtsberatung, keine Zertifizierung und keine Konformitätsgarantie. Er beschreibt einen strukturierten Prüf- und Dokumentationsansatz.