Barrierefreie Dokumente: Rechnungen und Datenblätter

Seit dem 28. Juni 2025 gilt das Barrierefreiheitsstärkungsgesetz für neu in Verkehr gebrachte Produkte und für Dienstleistungen im elektronischen Geschäftsverkehr (BFSG). In den meisten Projekten endet die Umsetzung am Rand des Browserfensters: Der Shop wird getestet, die Kontraste werden korrigiert, die Tastaturbedienung wird nachgezogen. Die PDF-Rechnung im Bestätigungsmail, das Datenblatt am Produkt und die Bedienungsanleitung im Downloadbereich bleiben unverändert. Genau diese Dokumente sind mitverpflichtet, und genau dort liegt in der Praxis der blinde Fleck der BFSG-Umsetzung.

Warum die Pflicht nicht am Rand des Browserfensters endet

Das Gesetz erfasst nach § 1 Absatz 2 Produkte, die nach dem 28. Juni 2025 in den Verkehr gebracht werden (BFSG), und daneben eine Reihe von Dienstleistungen, zu denen der Handel im elektronischen Geschäftsverkehr zählt. Barrierefrei ist nach § 3 Absatz 1 das, was für Menschen mit Behinderungen in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe auffindbar, zugänglich und nutzbar ist (BFSG). Diese Formulierung kennt keine Ausnahme für Anhänge. Wer eine Bestellung annimmt und die Rechnung als PDF verschickt, erbringt seine Dienstleistung nicht nur im Browser, sondern auch in diesem Anhang. Die Grundpflichten und ihre Fristen ordnet unser Beitrag zur Umsetzung des BFSG im Handel ein.

Die Größenordnung der betroffenen Gruppe wird regelmäßig unterschätzt. Zum Jahresende 2025 lebten in Deutschland gut 7,8 Millionen Menschen mit einer schweren Behinderung (Statistisches Bundesamt). Das entsprach 9,4 Prozent der Bevölkerung (Statistisches Bundesamt). Bei 4 Prozent der schwerbehinderten Menschen lag Blindheit oder eine Sehbehinderung vor (Statistisches Bundesamt). Hinzu kommen Menschen mit motorischen Einschränkungen, kognitiven Einschränkungen und eine wachsende Zahl älterer Kundinnen und Kunden, die mit vergrößerter Schrift arbeiten. Für diese Gruppe entscheidet sich am Dokument, ob eine Bestellung nachvollziehbar bleibt oder ob der Rechnungsbetrag vorgelesen wird, bevor klar ist, wozu er gehört.

Konkret wird die Pflicht in der Verordnung zum Barrierefreiheitsstärkungsgesetz. § 12 Nummer 2 verlangt für Dienstleistungen unter anderem, dass der Informationsinhalt in Textformaten zur Verfügung gestellt wird, die sich zum Generieren alternativer assistiver Formate durch den Verbraucher eignen (BFSGV). Buchstabe f nennt ausdrücklich Schriftart, Schriftgröße, Kontrast und Abstände (BFSGV). Buchstabe g verlangt eine alternative Darstellung des Inhalts, wenn Elemente nicht-textlichen Inhalts enthalten sind (BFSGV). Buchstabe h fasst zusammen, dass die für die Erbringung der Dienstleistung erforderlichen digitalen Informationen wahrnehmbar, bedienbar, verständlich und robust bereitzustellen sind (BFSGV). Eine Rechnung ist eine für die Erbringung der Dienstleistung erforderliche digitale Information. Ein Datenblatt, das die Kaufentscheidung trägt, ebenfalls.

Die Prüfmatrix: Dokumenttyp gegen Anforderung

Nicht jede Anforderung trifft jedes Dokument gleich hart. Eine Rechnung enthält typischerweise ein Logo, eine Tabelle mit Positionen und einen Fließtext mit Zahlungsbedingungen. Eine Bedienungsanleitung enthält Abbildungen, Warnhinweise und Verweise zwischen Kapiteln. Ein ausfüllbares Reklamationsformular enthält zusätzlich Eingabefelder. Wer alle Dateien mit derselben Checkliste bearbeitet, verliert Zeit an Anforderungen, die im Einzelfall nicht greifen, und übersieht die, die greifen. Die folgende Matrix ordnet die fünf praktisch wichtigsten Anforderungen den Dokumenttypen zu, die in einem Shop entstehen.

Die Spalten sind keine Hausmeinung, sondern die Erfolgskriterien der WCAG in der Fassung, die Kapitel 10 der Norm auf Dokumente überträgt (ETSI). Wer diese Zuordnung einmal für den eigenen Dokumentenbestand aufstellt, hat den Prüfplan für alle folgenden Vorlagenänderungen. Welche Kriterien mit der Fassung 2.2 hinzugekommen sind und was davon auf Dokumente durchschlägt, ordnet unser Beitrag zu den neuen Erfolgskriterien der WCAG 2.2 ein. Der praktische Wert der Matrix liegt darin, dass sie die Diskussion vom Format auf den Inhalt verschiebt: Nicht das PDF ist das Problem, sondern das PDF ohne Struktur.

Tagging: die unsichtbare Struktur im PDF

Ein PDF speichert zunächst nur, an welcher Stelle der Seite welches Zeichen in welcher Schrift steht. Für das Auge ergibt das eine Überschrift, eine Tabelle und eine Fußzeile. Für eine Vorlesesoftware ergibt das eine ungeordnete Menge von Textfragmenten. Die Brücke zwischen beidem ist der Tag-Baum: eine zweite, unsichtbare Schicht im Dokument, die festhält, dass eine Zeile eine Überschrift ist, dass ein Block eine Tabelle mit Kopfzeile ist und dass eine Grafik dekorativ oder inhaltstragend ist. Kapitel 10 überträgt dafür das Erfolgskriterium zu Informationen und Beziehungen auf Dokumente (ETSI): Struktur und Beziehungen, die visuell vermittelt werden, müssen programmatisch bestimmbar sein.

• Überschriften brauchen eine Ebene, keine größere Schrift. Eine fett gesetzte Zeile ohne Tag ist für die Sprachausgabe ein Absatz wie jeder andere.
• Tabellen brauchen ausgezeichnete Kopfzellen. Ohne sie liest die Sprachausgabe die Positionstabelle einer Rechnung als eine lange Zahlenkette ohne Bezug zur Spalte.
• Listen brauchen Listen-Tags. Zahlungsbedingungen, die als Absätze mit vorangestelltem Bindestrich gesetzt sind, verlieren beim Vorlesen ihren Zusammenhang.
• Dekorative Elemente brauchen eine Kennzeichnung als Artefakt. Trennlinien, Wasserzeichen und Hintergrundflächen gehören nicht in den Lesefluss.
• Seitenkopf und Seitenfuß gehören ebenfalls als Artefakt markiert, sonst wiederholt die Sprachausgabe die Anschrift auf jeder Seite.

Tagging entsteht selten von Hand. Es entsteht im Erzeuger. Wenn die Rechnungsvorlage aus einer Textverarbeitung oder aus einer Vorlagensprache im Shop erzeugt wird, entscheidet dort die Auszeichnung darüber, ob im PDF ein Tag-Baum landet. Genau deshalb ist die Umstellung ein Thema für die Entwicklung der Vorlagen und nicht für ein nachträgliches Werkzeug. Ein nachträglich getaggtes Dokument muss bei jeder Vorlagenänderung erneut bearbeitet werden. Ein Erzeuger, der sauber taggt, liefert die Struktur bei jedem Lauf mit.

Lesereihenfolge: wenn die Rechnung quer vorgelesen wird

Die zweite Schicht neben dem Tag-Baum ist die Reihenfolge. Das Erfolgskriterium 1.3.2 verlangt, dass eine korrekte Lesereihenfolge programmatisch bestimmbar ist, wenn die Reihenfolge, in der Inhalte dargestellt werden, ihre Bedeutung beeinflusst (W3C). Kapitel 10.1.3.2 überträgt genau dieses Kriterium auf Dokumente, die keine Webseite sind (ETSI). In der Praxis bricht das an mehrspaltigen Layouts: Eine Rechnung mit Absenderblock links, Empfängerblock rechts und Positionstabelle darunter wird von der Sprachausgabe in der Reihenfolge vorgelesen, in der die Blöcke im Dokument stehen, nicht in der Reihenfolge, in der das Auge sie erfasst.

Die häufigste Rückmeldung aus Nutzertests mit Sprachausgabe lautet nicht, dass etwas fehlt. Sie lautet, dass die Reihenfolge nicht zur Bedeutung passt.

XICTRON Entwicklungsteam

Die Prüfung ist unaufwendig und braucht kein Fremdsystem: Das Dokument wird in eine reine Textfassung überführt und die entstehende Reihenfolge gelesen. Steht der Rechnungsbetrag vor der Positionstabelle, steht die Fußzeile mitten im Zahlungshinweis oder taucht die Kundennummer erst nach den Zahlungsbedingungen auf, ist die Reihenfolge falsch. Ein weiterer Kandidat ist der Dokumenttitel. Kapitel 10.2.4.2 verlangt einen Titel, der Thema oder Zweck des Dokuments beschreibt (ETSI). Der Dateiname allein reicht dafür nicht; die Titel-Eigenschaft im Dokument muss gefüllt sein, sonst meldet die Sprachausgabe eine Zeichenkette aus Auftragsnummer und Zeitstempel. Warum Werkzeuge, die solche Defizite von außen zu überdecken versuchen, das Problem verschieben statt es zu lösen, beschreibt unser Beitrag zu Barrierefreiheits-Widgets.

Alternativtexte im Dokument

Das Erfolgskriterium 1.1.1 verlangt für nicht-textliche Inhalte eine Textalternative, die dem gleichen Zweck dient (W3C). Im Web ist das nach dem Kontrast der am zweithäufigsten gemessene Defekt: Auf 53,1 Prozent der untersuchten Startseiten fehlten Alternativtexte für Bilder (WebAIM). Es gibt keinen Grund anzunehmen, dass die Quote in Dokumenten besser ausfällt, denn dort fehlt zusätzlich die Gewohnheit, überhaupt danach zu fragen. In einer Rechnung sind die typischen Kandidaten überschaubar, und gerade deshalb lohnt eine feste Regel je Bildtyp statt einer Einzelfallentscheidung.

• Firmenlogo: Alternativtext ist der Firmenname, nicht die Beschreibung der Bildmarke.
• Barcode oder Matrixcode: Alternativtext ist der codierte Wert im Klartext, etwa die Sendungsnummer.
• Signaturgrafik: Alternativtext nennt die unterzeichnende Rolle, nicht den Schriftzug.
• Diagramm im Datenblatt: Alternativtext nennt die Aussage; die Wertetabelle gehört zusätzlich als getaggte Tabelle in das Dokument.
• Trennlinie, Farbfläche, Wasserzeichen: kein Alternativtext, sondern Kennzeichnung als Artefakt.
• Warnsymbol in der Anleitung: Alternativtext nennt die Warnstufe, weil die Farbe allein die Bedeutung nicht transportiert.

Die Alternativtexte für Produktbilder folgen derselben Logik wie im Shop, nur dass sie im Dokument aus dem Datenmodell in die Vorlage gereicht werden müssen. Wie sich die Texte im Produktdatenbestand pflegen und prüfen lassen, beschreibt unser Beitrag zu Alternativtexten für Produktbilder. Wichtig ist die Trennung: Ein Alternativtext, der das Bild beschreibt, ist selten hilfreich. Ein Alternativtext, der die Funktion des Bildes an dieser Stelle beschreibt, ist es in aller Regel wieder verwendbar.

Formularfelder in ausfüllbaren PDF

Sobald ein Dokument Eingabefelder enthält, kommt eine weitere Ebene hinzu. Das Erfolgskriterium 3.3.2 verlangt Beschriftungen oder Anweisungen, wenn Inhalte eine Nutzereingabe erfordern (W3C). Kapitel 10.3.3.2 überträgt das auf Dokumente (ETSI). Im Web fehlt diese Beschriftung erstaunlich oft: Auf 51 Prozent der untersuchten Startseiten wurden fehlende Formularbeschriftungen gemessen (WebAIM). In einem Reklamations- oder Widerrufsformular als PDF wiegt der Defekt schwerer, weil es keine zweite Eingabemöglichkeit daneben gibt.

1. Jedes Feld bekommt einen eindeutigen Namen und eine sichtbare Beschriftung, die programmatisch mit dem Feld verbunden ist.
2. Pflichtfelder werden als solche ausgezeichnet, nicht nur mit einem Sternchen versehen.
3. Die Aktivierreihenfolge folgt der Lesereihenfolge; springt der Fokus von der Anschrift in die Unterschriftszeile und zurück, ist die Reihenfolge falsch gesetzt.
4. Fehlermeldungen und Formathinweise stehen als Text im Dokument, nicht als Erläuterung in einer Randgrafik.
5. Gruppen zusammengehöriger Felder erhalten eine gemeinsame Beschriftung, damit die Sprachausgabe den Bezug ankündigt.
6. Der Fokus bleibt sichtbar; ein Feld ohne erkennbaren Fokusrahmen ist mit der Tastatur schwer zu bedienen.

Solche Anforderungen gehören in die Ausschreibung, nicht in die Abnahme. Wer sie erst beim Test formuliert, verhandelt über Nachträge. Wie sich Anforderungen an Dokumente sauber in ein Lastenheft für ein Shop-Projekt schreiben lassen, zeigt der Beitrag dieser Woche zum Thema. Als Faustregel hat sich bewährt, für jeden Dokumenttyp ein Musterdokument als Abnahmegegenstand zu benennen, statt die Anforderung abstrakt zu formulieren.

Sprachauszeichnung: Deutsch, Englisch, Produktname

Kapitel 10.3.1.1 verlangt, dass die vorgegebene menschliche Sprache eines Dokuments programmatisch bestimmbar ist (ETSI). Das ist die Stellschraube, die über die Aussprache entscheidet: Eine Sprachausgabe, die ein deutsches Dokument mit englischer Stimme vorliest, macht aus einer Rechnung ein Rätsel. Der zugehörige Grundsatz aus den Erfolgskriterien verlangt dasselbe für jede Webseite (W3C). Wie oft die Angabe fehlt, zeigt die Messung im Web: Auf 13,5 Prozent der untersuchten Startseiten fehlte die Angabe der Dokumentsprache (WebAIM). In Dokumenten ist die Quote erfahrungsgemäß höher, weil viele Erzeuger die Sprache aus der Systemeinstellung des Servers übernehmen.

Was der Rechnungsversand daraus macht

In der Praxis scheitert Dokumentenbarrierefreiheit selten am Willen und häufig am Weg. Zwischen Shop und Postfach liegen mehrere Stationen, und jede kann die Struktur verlieren. Der Shop erzeugt eine Rechnung, das Warenwirtschaftssystem erzeugt eine zweite, der Versanddienstleister legt eine dritte bei. Wird das Dokument unterwegs gedruckt und erneut eingescannt, ist der Tag-Baum verschwunden und übrig bleibt ein Bild. Wird es zusammengeführt, entsteht ein Sammel-PDF, dessen Lesereihenfolge niemand gesetzt hat. Wird es signiert, kommt eine Schicht hinzu, die manche Erzeuger dazu bringt, das Dokument neu zu schreiben.

Der strukturierte Rechnungsaustausch hilft dabei mehr, als viele erwarten. Ein hybrides Rechnungsformat legt die maschinenlesbaren Daten als Anhang in das PDF; die eingebettete Datenstruktur ist für sich genommen bereits ein Textformat im Sinne von § 12 Nummer 2 Buchstabe e (BFSGV), weil sich daraus alternative Darstellungen erzeugen lassen. Die Sichtkomponente bleibt trotzdem prüfpflichtig, denn sie ist das, was die meisten Empfänger öffnen. Wie sich beide Seiten in einem Shop sauber verdrahten lassen, beschreiben wir auf der Seite zu ZUGFeRD und XRechnung sowie im Beitrag zur E-Rechnungspflicht im Handel.

• Die Sichtkomponente der Rechnung trägt einen Tag-Baum und einen gefüllten Dokumenttitel.
• Die Positionstabelle hat ausgezeichnete Kopfzellen und eine geprüfte Lesereihenfolge.
• Storno- und Gutschriftbelege verwenden dieselbe Vorlage wie die Rechnung, damit die Struktur nicht nur im Standardfall stimmt.
• Der Versandweg erzeugt kein Rasterbild aus dem getaggten Dokument.
• Sammel-PDF aus mehreren Belegen behalten je Beleg ihre Struktur und ihren Titel.
• Die Sprachangabe im Dokument stammt aus der Bestellung, nicht aus der Serverumgebung.

Der dritte Punkt der Liste wird oft übersehen. Storno- und Gutschriftbelege entstehen in vielen Shops aus einer eigenen, historisch gewachsenen Vorlage, die denselben Weg durch die Qualitätssicherung nur selten genommen hat wie die Rechnung. Welche Sonderfälle dabei auftreten, haben wir im Beitrag zu Stornorechnungen und Gutschriften beschrieben. Es lohnt sich, den Prüfumfang bewusst auf diese Nebenbelege auszudehnen, weil sie im Streitfall dieselbe Beweiskraft haben wie die Hauptrechnung.

Datenblätter, Anleitungen und der Rest der Bibliothek

Rechnungen entstehen automatisiert und lassen sich deshalb an einer Stelle reparieren. Datenblätter, Konformitätserklärungen und Bedienungsanleitungen kommen dagegen meist vom Hersteller und liegen als fertige Datei im Downloadbereich. Hier stellt sich die Frage nach der Verantwortung. Die Antwort ist unbequem: Wer die Datei im eigenen Shop zum Abruf bereitstellt, stellt damit Information für die eigene Dienstleistung bereit und fällt unter § 12 Nummer 2 Buchstabe h (BFSGV). Ein Verweis auf den Hersteller ändert daran wenig. Praktisch führt das zu drei Wegen, die sich kombinieren lassen: den Hersteller in der Lieferantenvereinbarung zu barrierefreien Dateien verpflichten, die Kerninformation zusätzlich als getaggte Fassung im Shop führen oder das Dokument im Haus nacharbeiten.

Für den zweiten Weg spricht mehr als die Rechtslage. Eine Kerninformation, die als strukturierter Text im Shop liegt, ist auch für die Suche, für den Vergleich und für die interne Verlinkung verwertbar. Das Dokument bleibt daneben bestehen, verliert aber seine Rolle als einziger Träger der Information. Bei sehr großen Beständen ist eine Priorisierung nach Umsatz und Abrufhäufigkeit sinnvoller als ein Rundumschlag: Die zwanzig meistabgerufenen Anleitungen decken erfahrungsgemäß einen erheblichen Teil der tatsächlichen Nutzung ab. Ob ein Kleinstunternehmen von den Pflichten ausgenommen ist, ist eine eigene Prüfung wert; die Abgrenzung beschreibt unser Beitrag zu den Ausnahmen für Kleinstunternehmen.

Ein Weg zur prüffähigen Dokumentenstrecke

Der dritte Punkt ist der, der über die Haltbarkeit entscheidet. Eine einmal reparierte Rechnungsvorlage bleibt selten unverändert: Ein neues Logo, eine zusätzliche Pflichtangabe oder eine Anpassung der Fußzeile genügt, um den Tag-Baum zu beschädigen. Ein automatisierter Lauf, der nach jeder Vorlagenänderung ein Musterdokument erzeugt und dessen Struktur gegen eine Sollvorgabe prüft, kostet einmal Aufwand und danach nichts mehr. Wie sich solche Läufe in eine Teststrecke einbinden lassen, beschreibt der Beitrag dieser Woche zur E2E-Testautomatisierung. Für die Bewertung des Bestands ist die Reihenfolge dieselbe wie im Frontend: erst messen, dann priorisieren, dann umbauen.