Barrierefreie PDF-Dokumente im Shop: Rechnungen, Kataloge, Datenblätter

1. Warum PDF-Dokumente im Shop oft komplett übersehen werden

Barrierefreiheitsprojekte konzentrieren sich fast immer auf die HTML-Seiten eines Shops: Kontraste, Formulare, Tastaturbedienbarkeit. PDF-Dokumente wie Rechnungen, Produktdatenblätter oder saisonale Kataloge laufen dabei häufig komplett unter dem Radar, obwohl sie rechtlich denselben Anforderungen unterliegen wie die Webseite selbst, sobald sie über eine öffentlich zugängliche oder für Kundinnen und Kunden nutzbare Fläche bereitgestellt werden.

Das Problem verschärft sich dadurch, dass PDF-Dokumente in Magento-Shops selten manuell erstellt werden, sondern automatisiert aus Vorlagen generiert werden, etwa Rechnungen über die eingebaute PDF-Engine oder Datenblätter über ein Export-Modul. Wird die zugrunde liegende Vorlage nicht barrierefrei aufgebaut, entstehen tausende nicht barrierefreie Dokumente, ohne dass ein Mensch die einzelne Datei jemals zu Gesicht bekommt.

2. Der PDF/UA-Standard: was er konkret verlangt

PDF/UA, offiziell ISO 14289, definiert präzise technische Anforderungen an barrierefreie PDF-Dokumente und ist damit für PDF das, was WCAG für HTML-Seiten ist. Der Standard verlangt unter anderem eine vollständige Tag-Struktur, in der jedes sichtbare Element einem semantischen Tag zugeordnet ist, eine logische Lesereihenfolge, die unabhängig vom visuellen Layout definiert ist, sowie Alternativtexte für alle informationstragenden Bilder und Grafiken.

Zusätzlich verlangt PDF/UA korrekt ausgezeichnete Tabellen mit Kopfzeilen, eine im Dokument hinterlegte Sprache, damit Screenreader die richtige Aussprache wählen, sowie durchsuchbaren, echten Text statt gerasterter Bilddaten. Ein Dokument, das diese Kriterien erfüllt, lässt sich mit einem automatisierten Prüfwerkzeug wie dem PAC-Checker maschinell validieren, was PDF/UA gegenüber vagen Barrierefreiheitsversprechen deutlich überprüfbarer macht.

3. Getaggte PDFs vs. gescannte Bilder: der fundamentale Unterschied

Eine gescannte Rechnung oder ein eingescanntes Datenblatt besteht aus Sicht des PDF-Formats nur aus einem Bild, unabhängig davon, wie klar und lesbar der Text darauf für sehende Nutzer wirkt. Ein Screenreader kann aus einem solchen Bild keinerlei Textinhalt extrahieren, es sei denn, im Vorfeld wurde eine Texterkennung durchgeführt, die selbst dann keine semantische Struktur wie Überschriften oder Tabellen liefert.

Eine getaggte PDF enthält dagegen eine unsichtbare, dem sichtbaren Layout überlagerte Struktur, den sogenannten Tag-Baum, in dem jedes Element als Überschrift, Absatz, Tabelle, Liste oder Bild ausgezeichnet ist. Genau diese Struktur liest ein Screenreader vor, unabhängig von der visuellen Anordnung auf der Seite, und genau diese Struktur fehlt bei einem reinen Bild-PDF vollständig, selbst wenn eine Texterkennung nachträglich einen durchsuchbaren Textlayer ergänzt hat.

4. Automatisch generierte Magento-Rechnungs-PDFs: das Kernproblem

Magentos eingebaute PDF-Erzeugung für Rechnungen, Lieferscheine und Gutschriften basiert auf einer einfachen, koordinatenbasierten Zeichenlogik: Texte, Linien und Tabellenzellen werden an festen X- und Y-Positionen auf die Seite gezeichnet, ohne dass dabei eine semantische Tag-Struktur entsteht. Für sehende Nutzer wirkt das Ergebnis wie eine ordentliche, tabellarisch aufgebaute Rechnung, für einen Screenreader ist es jedoch lediglich eine Ansammlung einzelner, nicht miteinander verknüpfter Textfragmente ohne erkennbare Reihenfolge oder Tabellenstruktur.

Wer den zugrunde liegenden PDF-Generator direkt austauscht, kann diese Lücke technisch schließen, etwa durch den Wechsel auf eine Bibliothek wie mPDF, die im UA-konformen Modus HTML-Quelltext mit semantischen Tags in eine getaggte PDF-Struktur überführt, statt Koordinaten blind auf ein leeres Blatt zu zeichnen.

<?php

declare(strict_types=1);

namespace Mironsoft\SeoSuite\Model\Pdf;

use Mpdf\Mpdf;

/**
 * Erzeugt getaggte, PDF/UA-konforme Rechnungen aus semantischem HTML
 * statt aus koordinatenbasierten Zeichenbefehlen.
 */
class AccessibleInvoicePdfGenerator
{
    /**
     * Rendert eine barrierefreie Rechnungs-PDF aus semantischem HTML-Markup.
     *
     * @param string $invoiceHtml Semantisches HTML mit table/th/caption-Struktur.
     * @param string $language Sprachcode für den Dokument-Tag, z. B. "de".
     * @return string Binärer PDF-Inhalt.
     */
    public function generate(string $invoiceHtml, string $language = 'de'): string
    {
        $mpdf = new Mpdf([
            'mode' => 'utf-8',
            'format' => 'A4',
            // Aktiviert die interne Tag-Baum-Erzeugung statt reiner
            // Koordinaten-Ausgabe.
            'tag_mode' => true,
        ]);

        $mpdf->docLang = $language;
        $mpdf->SetTitle('Rechnung');

        $mpdf->WriteHTML($invoiceHtml);

        return $mpdf->Output('', 'S');
    }
}

5. Tools zur Nachbearbeitung: Adobe Acrobat Tags-Panel

Wenn sich der PDF-Generator nicht direkt austauschen lässt oder ein bestehender Bestand an PDF-Dokumenten korrigiert werden muss, bleibt die manuelle oder halbautomatische Nachbearbeitung über Adobe Acrobat Pro. Das Werkzeug Barrierefreiheit prüfen erzeugt zunächst automatisch einen groben Tag-Baum, der sich anschließend im Tags-Panel manuell verfeinern lässt: falsch erkannte Überschriftenebenen korrigieren, fehlende Tabellen-Tags ergänzen, Lesereihenfolge per Ziehen und Ablegen anpassen.

Besonders wichtig ist im Tags-Panel die korrekte Auszeichnung von Tabellen mit TH-Zellen für Kopfzeilen, da Magento-Rechnungen typischerweise mehrere Tabellen enthalten, etwa für Positionen, Versandkosten und Zahlungsdaten, die ohne saubere Tag-Struktur für Screenreader-Nutzer zu einer bedeutungslosen Ansammlung einzelner Zahlen werden. Ergänzend lässt sich über den Alternativtext-Assistenten jedem Logo und jeder Grafik im Dokument ein passender Alternativtext zuweisen.

6. PAC-Checker: automatisierte Prüfung der PDF/UA-Konformität

Der PAC-Checker, kostenlos von der Access for All Stiftung bereitgestellt, prüft ein PDF-Dokument automatisiert gegen die technischen Kriterien von PDF/UA und meldet konkrete, nach Schweregrad sortierte Fehler wie fehlende Alternativtexte, eine nicht deklarierte Dokumentsprache oder eine unvollständige Tag-Struktur. Anders als eine rein visuelle Kontrolle liefert PAC damit ein objektives, reproduzierbares Prüfergebnis, das sich auch in einen Qualitätssicherungsprozess für automatisiert erzeugte Rechnungen integrieren lässt.

In der Praxis empfiehlt sich, den PAC-Checker nicht nur einmalig bei der Einführung eines neuen PDF-Templates einzusetzen, sondern stichprobenartig auch nach jedem größeren Magento-Update erneut zu prüfen, da Änderungen an der zugrunde liegenden PDF-Bibliothek oder am Rechnungslayout die zuvor erreichte Konformität unbemerkt wieder zerstören können.

7. Kataloge und Datenblätter: der redaktionelle Workflow

Anders als automatisiert generierte Rechnungen entstehen Produktkataloge und technische Datenblätter meist in einem Layoutprogramm wie Adobe InDesign, bevor sie als PDF exportiert werden. Genau an dieser Exportstelle entscheidet sich, ob das Ergebnis barrierefrei wird: InDesign erlaubt es, Absätze, Überschriften und Tabellen bereits im Layout mit semantischen Rollen zu versehen, die beim Export als PDF/UA-Struktur direkt übernommen werden, statt sie nachträglich mühsam in Acrobat zu rekonstruieren.

Für die redaktionelle Praxis bedeutet das, dass Barrierefreiheit nicht am Ende eines Katalogprojekts als Nachbesserung stattfinden sollte, sondern bereits bei der Erstellung der InDesign-Vorlage mitgedacht werden muss, inklusive konsequenter Nutzung des Absatzformat-Exportmappings und einer sinnvollen Lesereihenfolge für mehrspaltige Layouts.

8. Praxisfall: eine Magento-Rechnungs-PDF Schritt für Schritt barrierefrei machen

Der pragmatischste Weg für einen bestehenden Magento-Shop kombiniert beide Ansätze: den PDF-Generator so umbauen, dass er von Anfang an eine getaggte Grundstruktur erzeugt, und stichprobenartige Nachprüfung mit PAC, um Regressionen frühzeitig zu erkennen. Im ersten Schritt wird die bestehende Rechnungsvorlage durch eine HTML-zu-PDF-Pipeline ersetzt, die auf einer semantischen HTML-Struktur mit table, th, caption und korrekt verschachtelten Überschriften aufbaut, wie im folgenden Ausschnitt einer Positionstabelle gezeigt.

Im zweiten Schritt wird jedes Logo und jede Grafik im Rechnungskopf mit einem Alternativtext versehen, die Dokumentsprache explizit auf Deutsch gesetzt und die Lesereihenfolge so definiert, dass sie der visuellen Reihenfolge entspricht: zuerst Absenderdaten, dann Rechnungsnummer und Datum, dann die Positionstabelle, zuletzt die Zahlungsinformationen. Ein anschließender Testlauf mit PAC bestätigt, ob die generierte Rechnung tatsächlich UA-1-konform ist, bevor die neue Vorlage produktiv geschaltet wird.

<table>
  <caption>Rechnungspositionen zu Rechnung Nr. 2026-04871</caption>
  <thead>
    <tr>
      <th scope="col">Artikel</th>
      <th scope="col">Menge</th>
      <th scope="col">Einzelpreis</th>
      <th scope="col">Gesamtpreis</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Sicherheitsschuh S3, Größe 43</td>
      <td>2</td>
      <td>89,90 Euro</td>
      <td>179,80 Euro</td>
    </tr>
  </tbody>
</table>

9. Alternative: HTML-Rechnungen statt PDF anbieten

Neben der Nachrüstung bestehender PDF-Vorlagen lohnt sich die grundsätzliche Frage, ob eine PDF-Rechnung überhaupt die richtige Ausgabeform ist. Eine als reguläre HTML-Seite im Kundenkonto dargestellte Rechnung profitiert automatisch von allen Barrierefreiheitsmaßnahmen, die für den restlichen Shop bereits umgesetzt sind, etwa korrekte Überschriftenhierarchie, Tastaturbedienbarkeit und responsives Layout, ohne dass eine separate PDF-Pipeline gepflegt werden muss.

Für viele Shops bietet sich deshalb ein hybrider Ansatz an: eine gut zugängliche HTML-Ansicht der Rechnung als primäre Darstellung im Kundenkonto, ergänzt um einen optionalen PDF-Download für Buchhaltungszwecke, der zwar weiterhin PDF/UA-konform aufgebaut sein sollte, aber nicht mehr die einzige verfügbare Darstellungsform der Rechnungsdaten darstellt.

Die folgende Tabelle vergleicht die vorgestellten Werkzeuge und ihre typischen Einsatzbereiche.

10. Zusammenfassung

11. FAQ: Barrierefreie PDF-Dokumente: Das Wichtigste auf einen Blick