Ihr VPAT deckt die App ab. Was ist mit den PDFs, die sie generiert?

Kurze Antwort: Dieses PDF fällt namentlich unter den Geltungsbereich der Standards, auf denen ein VPAT basiert – es ist kein Graubereich, den Sie für später aufschieben können. Der Abschnitt, in dem dies schiefgeht, ist derjenige, der Nicht-Web-Dokumente abdeckt, und zwar aus einem bestimmten Grund: Wer ein VPAT ausfüllt, testet das Produkt, das er täglich verwendet – die Web-App, das Dashboard, den Einstellungsbildschirm –, während der Exportpfad etwas ist, auf das man einmal klickt, einen kurzen Blick darauf wirft und dann weitermacht. Eine VPAT-Vorlage lässt Dokumente nicht aus. Teams tun das.

Was ein VPAT eigentlich ist und welches Sie senden sollten

Das VPAT – Voluntary Product Accessibility Template – wird vom Information Technology Industry Council (ITI) herausgegeben, und ein ausgefülltes Exemplar ist das, was Käufer als Accessibility Conformance Report (ACR) bezeichnen. Die aktuelle Version ist VPAT 2.5Rev, April 2025, veröffentlicht in vier Ausgaben auf der VPAT-Seite des ITI: 508 (nur überarbeiteter Abschnitt 508), EU (nur EN 301 549), WCAG (nur WCAG 2.0/2.1/2.2) und INT, das alle drei Standards in einem Dokument zusammenfasst. Regierungsaufträge nennen normalerweise den Standard, was Ihnen die Ausgabe vorgibt; im Zweifelsfall deckt die INT-Ausgabe alle Zielgruppen gleichzeitig ab.

Es ist gut zu wissen, bevor Sie die falsche VPAT-Vorlage herunterladen: Die eigene Anleitung für Auftragnehmer von Section508.gov nennt immer noch 2.4 als „aktuelle Version“, während die ITI-Website bereits auf 2.5Rev umgestellt hat. Beide haben auf ihre Weise recht – Section508.gov sagt auch, dass „jedes VPAT 2.x akzeptabel ist“ –, aber selbst Referenzseiten der Bundesbehörden hinken dem Herausgeber hinterher. Der sicherste Weg ist, die Vorlage von itic.org zu beziehen, anstatt von einem Link, den ein Kollege vor zwei Jahren als Lesezeichen gespeichert hat.

Das Vokabular, auf das Sie sich festlegen

Ein VPAT erlaubt es Ihnen nicht, die Konformität mit eigenen Worten zu beschreiben. Jedes Kriterium erhält einen von vier Begriffen, und die Vorlage selbst definiert diese präzise:

• Supports (Unterstützt) – „(aus dem Englischen übersetzt) Die Funktionalität des Produkts verfügt über mindestens eine Methode, die das Kriterium ohne bekannte Mängel erfüllt oder eine gleichwertige Erleichterung bietet.“
• Partially Supports (Unterstützt teilweise) – „Einige Funktionen des Produkts erfüllen das Kriterium nicht.“
• Does Not Support (Unterstützt nicht) – „Der Großteil der Produktfunktionalität erfüllt das Kriterium nicht.“
• Not Applicable (Nicht anwendbar) – „Das Kriterium ist für das Produkt nicht relevant.“

Es gibt einen fünften Begriff, Not Evaluated (Nicht bewertet), der nur für WCAG Level AAA-Kriterien reserviert ist – er ist keine Möglichkeit, ein Kriterium zu überspringen, das Sie auf Level A oder AA einfach nicht überprüft haben. Und die Anweisungen des ITI sind direkt bezüglich dessen, wer für die Antwort verantwortlich ist: „(aus dem Englischen übersetzt) Es liegt in der Verantwortung des Anbieters, die Integrität der Daten im Bericht zu wahren.“ Welches Wort auch immer in dieser Zelle steht, ist Ihre Behauptung, nicht die der Vorlage.

Dokumente werden explizit genannt, nicht impliziert

Zwei Standards machen den Geltungsbereich explizit, und keiner behandelt „Dokumente“ als nachträglichen Einfall zum Web.

EN 301 549

EN 301 549, der von ETSI veröffentlichte ICT-Barrierefreiheitsstandard der EU (die aktuell im VPAT der EU-Ausgabe referenzierte Version ist V3.2.1 (2021-03)), gibt Nicht-Web-Dokumenten eine eigene Klausel. Klausel 10.0 legt den Geltungsbereich in klaren Worten fest: Sie deckt „Dokumente, die keine Webseiten sind“, Dokumente, die „nicht in Webseiten eingebettet sind“, und – das ist der Teil, den Export-Funktionen übersehen – Dokumente, die „mit Webseiten bereitgestellt werden, aber... weder eingebettet noch zusammen mit der Webseite, von der sie bereitgestellt werden, gerendert werden“, ab, was die Klausel einfach als „herunterladbare Dokumente“ bezeichnet. Eine PDF-Rechnung, die Ihr Produkt generiert und die ein Benutzer herunterladen kann, ist genau das, wofür Klausel 10 geschrieben wurde.

Section 508

Section 508 erreicht dasselbe PDF aus zwei Richtungen in den ICT-Standards des Access Board. E205 definiert „elektronische Inhalte“, die öffentlich zugänglich sind oder für offizielle Geschäfte verwendet werden, und verlangt, dass sie WCAG 2.0 Level A und AA erfüllen. Und 504.2, im Software-Kapitel, geht noch weiter zurück – auf das Werkzeug, das das Dokument erstellt hat: „(aus dem Englischen übersetzt) Authoring-Tools müssen einen Betriebsmodus bereitstellen, um Inhalte zu erstellen oder zu bearbeiten, die den Erfolgskriterien und Konformitätsanforderungen von Level A und Level AA in WCAG 2.0 entsprechen... für Dateiformate, die vom Authoring-Tool unterstützt werden.“ Wenn Ihr Produkt PDFs exportiert, ist Ihr Produkt nach den eigenen Begriffen des Standards ein Authoring-Tool. Die Dokumentenzeile des VPAT fragt nicht nach einem PDF, das ein Kunde zufällig hochgeladen hat – wenn der Export eine Funktion ist, fragt sie nach Ihrem Exportpfad.

Was unsere eigene Messung über diesen Pfad zeigt

Wir haben 59 aus Word exportierte PDFs aus dem öffentlichen Sektor validiert – die Gesamtheit ist in unserem früheren Artikel über den Barrierefreiheits-Checker von Word beschrieben – gegen PDF/UA-1 mit veraPDF 1.30.2 (Build 2026-06-03). Sie brauchen kein Terminal, um dieselben Fehler in Ihrem eigenen Export zu sehen: Jeder PDF/UA-Validator meldet sie, auch der Checker, der am Ende dieses Artikels verlinkt ist.

~/.local/share/verapdf/verapdf -f ua1 --format json document.pdf

Keines der 59 entsprach den Anforderungen. Die drei häufigsten Fehler waren:

Ein fehlender Titel ist das dokumentenbezogene Analogon zu WCAG 2.4.2 Page Titled – das ist der Grund, warum ein Screenreader einen Dateinamen anstelle eines Dokumentnamens ansagt. Nicht eingebettete Schriftarten untergraben eine zuverlässige Textextraktion, von der die meisten Anforderungen unter „Wahrnehmbar“ und „Robust“ der Klausel 10 letztendlich abhängen. Ein Produkt, dessen Standard-Exportpfad solche Dateien erzeugt, hat keine ehrliche Möglichkeit, Supports in die Zeilen für Nicht-Web-Dokumente seines VPAT zu schreiben. Der korrekte Eintrag ist bestenfalls „Partially Supports“, wobei der spezifische Fehler in der Spalte „Remarks and Explanations“ genannt wird – was die Vorlage immer dann erfordert, wenn die Antwort kein sauberes „Supports“ ist.

Wie ein „Supports“-Anspruch tatsächlich überprüft wird

Niemand beim ITI testet Ihr Produkt, bevor Sie ein VPAT veröffentlichen. Die Vorlage hat keine Zertifizierungsstelle im Hintergrund: Niemand gibt die Angaben frei, bevor Sie sie veröffentlichen, und die Ehrlichkeit bleibt ungeprüft, bis jemand eine Ihrer Dateien herunterlädt.

Es gibt zwei Mechanismen für diese Überprüfung, und beide bürden die Last dem Käufer auf. Erstens erfordert jedes VPAT ein Feld Evaluation Methods Used, das „die durchgeführten Tests“ beschreibt – ob manuell, automatisiert oder durch Tester, die das Produkt kennen. Eine Reihe von „Supports“-Einträgen, die durch „wir haben einen automatisierten Scanner ausgeführt“ gestützt werden, und eine, die durch „getestet mit NVDA und JAWS von einem Tester, der mit dem Produkt nicht vertraut ist“ gestützt wird, sind nicht derselbe Anspruch, auch wenn in der Zelle dasselbe Wort steht. Zweitens weist die eigene Beschaffungsanleitung von Section508.gov Bundeskäufer an, nicht beim Dokument stehen zu bleiben: (aus dem Englischen übersetzt) „Vertrauen, aber überprüfen: Führen Sie vor der Vergabe eines Auftrags... Barrierefreiheitstests durch, um zu validieren, dass die betreffenden Technologieprodukte und -dienste vollständig barrierefrei sind“, da „eine Expertenprüfung der Section 508-Konformitätsansprüche einen Hinweis auf die Barrierefreiheit geben kann, [aber] strenge Tests erforderlich sind, um diese Ansprüche zu validieren.“ Einige Bundesvertragsklauseln gehen weiter und verlangen vom Anbieter, diese Tests selbst durchzuführen und die Ergebnisse vor der Vergabe zu übergeben.

In der Praxis: Ein VPAT, das auf dem Papier gut aussieht, wird früher oder später an den tatsächlichen Dateien getestet, die es zu abdecken behauptet, und zwar von jemandem, der die PDF-Ausgabe Ihres Produkts heruntergeladen und in einem Screenreader oder Validator geöffnet hat. Sorgfältige Käufer öffnen diese Datei früh, und die Lücke zwischen dem Anspruch und der Datei ist meist das Erste, was sie finden.

Was ein VPAT einem Käufer wirklich nicht sagen kann

Zwei Grenzen sind es wert, klar ausgesprochen zu werden, da ein vertriebsorientiertes Dokument jeden Anreiz hat, sie zu überspringen.

PDF/UA-1 – der Standard, gegen den unsere eigene Messung oben testet – ist nicht derselbe Test wie die WCAG-basierten Kriterien, die Klausel 10 von EN 301 549 und E205 von Section 508 tatsächlich spezifizieren. Die beiden überschneiden sich stark bei Struktur, Titeln und Lesereihenfolge, aber sie sind nicht austauschbar: Eine Datei kann die mechanischen Prüfungen von PDF/UA-1 bestehen und dennoch ein WCAG-formuliertes Kriterium verfehlen, das Klausel 10 verlangt, oder umgekehrt. Ein „Supports“, das nur durch einen PDF/UA-Durchlauf gestützt wird, ist ein Indiz, kein Beweis für die Zeile, gegen die es geschrieben wurde.

Und ein VPAT beschreibt eine Version des Standardverhaltens eines Produkts zu einem bestimmten Zeitpunkt. Es sagt nichts über die nächste Version aus, und – für jedes Produkt, bei dem ein Benutzer den Inhalt bereitstellt, anstatt dass das Produkt einen festen Bericht generiert – kann es nicht versprechen, dass jedes Dokument, das ein Kunde damit erstellt, mit dem getesteten Beispiel übereinstimmt. Dieser Vorbehalt überlebt selten das Verkaufsgespräch, aber er gehört dazu, wie ein Käufer das Dokument liest, nicht nur dazu, wie ein Anbieter es schreibt.

Wo man anfangen sollte

Bevor jemand in Ihrem Team ein Wort in die Dokumentenzeile schreibt, exportieren Sie die Datei, die Ihr Produkt tatsächlich produziert, und betrachten Sie sie so, wie es ein Käufer irgendwann tun wird. Unser PDF-Barrierefreiheits-Checker führt eine strukturelle Prüfung durch – Tagging, Titel, Sprache, Alternativtext – gegen eine Datei, die Sie hineinziehen, ohne sie irgendwo hochzuladen, und die PDF/UA-Fehlerreferenz erklärt, was jeder Fehler bedeutet, falls Sie Klausel für Klausel vorgehen möchten. Betrachten Sie das als Ausgangspunkt, nicht als Antwort: Eine bestandene Strukturprüfung sagt Ihnen, dass die Datei nicht offensichtlich kaputt ist, und die „Supports“-Zeile verlangt weiterhin das, was die Beschaffungsleitfäden fordern – jemanden, der die Datei mit einem Screenreader öffnet.

Wenn Ihre Organisation auch das US-Rechtsbild über das VPAT hinaus benötigt – ADA Title II-Fristen neben Section 508 –, wird dies auf unserer Section 508- und ADA-Compliance-Seite behandelt. Und wenn die Frage stattdessen von der EU-Seite kam – eine öffentliche Barrierefreiheitserklärung anstelle eines Beschaffungsformulars – ist unser Artikel darüber, was diese Erklärung Dokumenten schuldet, die Ergänzung zu diesem hier.