Barrierefreiheitsberichte für Softwarehersteller

Ein VPAT-Konformitätsbericht (Accessibility Conformance Report, ACR) ist das Dokument, das Einkäufer verlangen, wenn sie wissen wollen, wie weit Ihr Produkt WCAG, EN 301 549 und Section 508 erfüllt. Ich prüfe Ihre Webanwendung und schreibe den ACR im Format VPAT® 2.5 Rev INT, das alle drei Standards in einem Bericht abdeckt. Auf Wunsch entwerfe ich auch eine Erklärung zur Barrierefreiheit für die EU. Jedes „Supports“ (unterstützt) in meinem Bericht beruht auf einem Testergebnis oder auf Code, den ich gelesen habe; was außerhalb des geprüften Umfangs lag, ist im Bericht benannt und wird nicht behauptet. Der ACR bleibt, was er ist: Ihre Selbsterklärung als Hersteller, kein Zertifikat.

Sie sind hier richtig, wenn einer dieser Punkte auf Sie zutrifft:

• Sie sind Softwarehersteller, und ein Kunde, eine Hochschule oder eine Behörde in den USA verlangt vor dem Kauf ein „VPAT“. Sie haben keines, oder Ihres beschreibt eine Version, die Sie nicht mehr ausliefern.
• Eine öffentliche Ausschreibung in Deutschland, Österreich oder der EU fordert Konformität mit EN 301 549 oder einen Konformitätsbericht mit dem Angebot.
• Ein Lieferantenfragebogen im Einkauf eines Konzerns enthält einen Abschnitt zur Barrierefreiheit, den Sie nicht belegen können.
• Ihr Produkt wird von Verbraucherinnen und Verbrauchern genutzt, und Sie brauchen die Informationen zur Barrierefreiheit, die BFSG oder BaFG verlangen.
• Sie haben bereits einen ACR, in dem jede Zeile „Supports“ lautet, und niemand kann zeigen, wie das geprüft wurde.

• Kopfdaten: Nennt Ihr ACR die Produktversion, das Berichtsdatum, die VPAT-Ausgabe und die Prüfmethoden? Ohne diese Angaben kann ein Einkäufer nicht erkennen, was geprüft wurde.
• Spalte Konformität: Steht in jeder Zeile „Supports“ und nirgends „Partially Supports“, rechnen Sie mit Rückfragen erfahrener Prüfer.
• Ihre eigene Anmeldeseite: Klicken Sie in die Adressleiste und drücken Sie wiederholt die Tabulatortaste. Sehen Sie an irgendeiner Stelle nicht, wo der Fokus steht, ist WCAG 2.4.7 nicht erfüllt, egal was der Bericht sagt.

Lesen Sie weiter für die technischen Details. Unten: was VPAT und ACR sind, eine gemessene Prüfung einer Demo-Webanwendung vor und nach der Überarbeitung (alle Dateien zum Download), was automatische Werkzeuge übersehen, und die Rechtslage in Deutschland, Österreich, der EU und den USA. Wenn Sie abkürzen möchten, senden Sie mir einen Link zu Ihrem Produkt und den Fragebogen, der den Bericht verlangt.

Das VPAT® ist eine leere Vorlage des Information Technology Industry Council (ITI); ein ACR ist diese Vorlage, ausgefüllt für eine Version eines Produkts. Einkäufer sagen oft „VPAT“, wenn sie den ausgefüllten Bericht meinen.

VPAT 2.5 gibt es in vier Ausgaben: 508, EU, WCAG und INT. Die INT-Ausgabe vereint WCAG, die Revised Section 508 Standards und EN 301 549 in einem Dokument. Jede WCAG-Zeile nennt auch den entsprechenden Abschnitt der EN 301 549 und die Section-508-Vorschrift; dasselbe Testergebnis wird so nur einmal berichtet.

Jede Zeile erhält einen von fünf Begriffen, die im Bericht englisch bleiben. Supports (unterstützt): Die Funktion erfüllt das Kriterium ohne bekannte Mängel. Partially Supports (teilweise unterstützt): Ein Teil erfüllt es nicht. Does Not Support (nicht unterstützt): Der überwiegende Teil erfüllt es nicht. Not Applicable (nicht anwendbar): Das Kriterium ist nicht relevant, etwa Untertitel in einem Produkt ohne Video. Not Evaluated (nicht bewertet): Niemand hat es geprüft. Die Regeln von VPAT 2.5 behalten diesen Begriff Kriterien der Stufe AAA vor; jede Zeile der Stufe A und AA braucht also eine echte Antwort. Deshalb kommt es auf den Umfang an: 2.4.5 braucht mehr als eine Seite, die Kapitel zu Dokumentation und Support brauchen Ihre Hilfe- und Supportinhalte.

WCAG 2.2 ist die aktuelle W3C-Empfehlung mit 55 Kriterien auf Stufe A und AA. EN 301 549 V3.2.1 baut auf WCAG 2.1 auf, die Revised Section 508 Standards verweisen weiterhin auf WCAG 2.0. WCAG 2.2 hat außerdem das Kriterium 4.1.1 Syntaxanalyse gestrichen, das die beiden älteren noch enthalten. Ein INT-Bericht enthält deshalb drei Teilmengen derselben Ergebnisse und weist 4.1.1 gesondert aus.

axe-core und ähnliche Werkzeuge testen, was sie an einem einzelnen Seitenzustand entscheiden können: Kontrast, fehlende Beschriftungen, fehlende alt-Attribute, fehlende Sprachangabe. Ob jemand mit der Tastatur hängen bleibt, ob ein Dialog den Fokus hält oder ob eine Fehlermeldung mit ihrem Feld verknüpft ist, erkennen sie nicht. Ein ACR, der nur auf einem Scan beruht, setzt diese Zeilen stillschweigend auf „Supports“.

Dies ist ein gemessenes Beispiel an einem fiktiven Produkt, kein Kundenauftrag. Ich habe eine kleine Webanwendung mit Anmeldung und Dashboard geschrieben und absichtlich Barrieren eingebaut. Version 1.1 erhielt zusätzlich eine Hilfe- und Dokumentationsseite, damit die Zeilen zu Dokumentation und Support im ACR an echtem Inhalt bewertet werden. Dann habe ich sie geprüft, korrigiert, mit denselben Skripten erneut geprüft und den ACR sowie die Erklärungen geschrieben. Alle Dateien können Sie unten herunterladen.

• Produkt: „Örnek Yazılım — Randevu Paneli“, ein Terminverwaltungs-Dashboard der fiktiven Firma Örnek Yazılım A.Ş. Die Oberfläche ist türkisch. Version 1.0 enthält die Barrieren, Version 1.1 ist die überarbeitete, mit Hilfeseite (deren Telefonnummer ein gekennzeichneter Platzhalter ist). Jede Ansicht, jeder Bericht und jede Erklärung ist als Beispiel gekennzeichnet. Der Code ist meine eigene Arbeit, ohne Inhalte Dritter.
• Automatisch: axe-core 4.13.0 mit den Tags für WCAG 2.0, 2.1 und 2.2, Stufe A und AA, in den Zuständen Anmeldung, Dashboard, Dashboard nach leerem Absenden des Formulars, geöffneter Dialog und sichtbare Benachrichtigung, in Version 1.1 zusätzlich auf der Hilfeseite. Dazu der Nu Html Checker.
• Skriptgesteuert: Playwright 1.56.0 mit Chromium 141: ein Durchlauf mit 70 Tabulator-Anschlägen samt Fallenerkennung, sichtbarer Fokus an jeder Station, Dialogverhalten, Live-Regionen, Fehlerverknüpfung, zugängliche Namen aus dem Barrierefreiheitsbaum des Browsers, Einfügen, Zielgröße, Layout bei 320 px und 640 px, Textabstände, Diagrammkontrast aus den Bildpixeln und eine Link-Inventur von Navigation, Fußzeile und Seitenliste auf jeder Seite.
• Manuell: Ich habe HTML, CSS und JavaScript sowie die Hilfe- und Supportinhalte gegen jedes Kriterium und jeden Abschnitt gelesen. Das ist Code-Inspektion, kein Screenreader-Test.

Meine eigene erste Korrektur hat nicht bestanden. Beim ersten Lauf von Version 1.1 war das Dashboard bei 320 px noch 373 px breit, weil visuell verborgener Text aus dem Scrollbereich der Tabelle herausragte. Das Skript hat es gefunden, ich habe es behoben. Ein zweiter Lauf fand auf der Hilfeseite 5 Listenlinks mit nur 17 px Höhe; sie haben jetzt eine Mindesthöhe von 24 px. Beide Läufe liegen im ZIP.

Von den 55 Kriterien der WCAG 2.2 auf Stufe A und AA unterstützt Version 1.0 13 und Version 1.1 40. Auch Version 1.1 ist nicht fehlerfrei, und der ACR sagt das.

Die Spalten EN 301 549 und Section 508 sind die Teilmengen WCAG 2.1 und WCAG 2.0 derselben Ergebnisse, jeweils einschließlich 4.1.1.

In Version 1.1 bleiben drei Zeilen offen:

• 2.2.1 Zeitvorgaben anpassbar — Does Not Support. Die Sitzung endet nach 15 Minuten ohne Warnung und ohne Verlängerungsmöglichkeit. Gefunden beim Lesen des JavaScript; kein Scan meldet das.
• 1.4.11 Nicht-Text-Kontrast — Partially Supports. Die helle Diagrammreihe hat gegen Weiß 1,81:1, unter den geforderten 3:1. Dieselben Werte stehen in einer Datentabelle unter dem Diagramm.
• EN 301 549 12.2.3 / Section 508 603.3 — Partially Supports. Die Hilfeseite bietet Support nur per E-Mail und Telefon an, ohne Gebärdensprache, Echtzeittext oder Vermittlungsdienst.

„Not Evaluated“ kommt im ACR einmal vor, in einer Zeile der Stufe AAA, wie es die Regeln von VPAT 2.5 verlangen. 2.4.5 Verschiedene Methoden ist Supports: Eine Link-Inventur zeigte, dass beide Seiten der Anwendung über das Hauptmenü und über die Seitenliste in der Fußzeile erreichbar sind. Die Zeilen zu Dokumentation und Support (Section 508 Kapitel 6, EN 301 549 Kapitel 12) wurden an der Hilfeseite und den dort veröffentlichten Supportangaben bewertet. Diese Seite habe ich wie das Produkt geprüft: axe 0, Nu Html Checker 0, kein Überlauf bei 320 px, keine zu kleinen Ziele, keine Links ohne Namen. Kapitel 6 ergibt 3 Supports, 1 Partially Supports und 1 Not Applicable (602.4, da es keine gedruckte Dokumentation gibt), EN 301 549 Kapitel 12 ergibt 4 Supports und 1 Partially Supports. Echte Supportgespräche gehörten nicht zur Stichprobe; die Bemerkungen sagen das. Die 11 funktionalen Leistungsmerkmale der EN 301 549 ergeben 6 Supports, 4 Partially Supports und 1 Not Applicable, abgeleitet aus den WCAG-Ergebnissen statt gesondert getestet. EN 301 549 Abschnitt 5 (außer 5.9, das Supports ist), die Kapitel 6–8, 10, 11 und 13 sowie Section 508 Kapitel 4 und 5 (501–504) sind Not Applicable, jeweils mit Begründung.

axe fand in Version 1.0 fünf Arten von Problemen. Die Skriptprüfungen und die Code-Durchsicht fanden 14 weitere, die axe überhaupt nicht markiert hat:

Eine Null im Scan und ein „ja“ im Skript sind Belege, kein Beweis für Barrierefreiheit. Diese Grenzen stehen auch im ACR selbst:

• Keine assistiven Technologien. Zugängliche Namen wurden aus dem Barrierefreiheitsbaum von Chromium gelesen. Das zeigt, was ein Screenreader erhalten kann, nicht, was NVDA, JAWS oder VoiceOver ansagen.
• Keine Tests mit Menschen mit Behinderungen. Die tatsächliche Gebrauchstauglichkeit wurde nicht bewertet.
• Eine Browser-Engine. Chromium unter Desktop-Linux; kein Firefox, kein Safari, kein mobiler Browser, keine erzwungenen Farben.
• Näherungen. 200 % Zoom wurde mit einem 640-px-Viewport angenähert; die Zielgröße ist eine Rechteckprüfung ohne Abstandsausnahme; die Textabstandsprüfung findet nur Abschneiden. Der Kontrast des Fokusindikators (6,29:1 und 5,8:1) wurde aus dem CSS berechnet.
• Urteil. Ob Alternativtexte, Beschriftungen, Überschriften und Fehlermeldungen aussagekräftig sind, und jede Entscheidung für Not Applicable, stammt von einem Menschen, der den Code liest.
• Zustände. axe sieht nur die sechs Zustände, die es erhält, nicht jeden Zustand der Anwendung. Im Dialog- und im Benachrichtigungszustand ließ es eine Prüfung offen: Kontrast über der Abdunklung und auf Schaltflächen nur mit Symbol. Von Hand nachgemessen: 17,22:1.
• Umfang. Verschiedene Methoden wurden per Link-Inventur über drei Seiten geprüft; ein echtes Produkt braucht dieselbe Prüfung über alle Seiten. Die Bewertung des Supports beruht auf den veröffentlichten Supportangaben, nicht auf echten Supportgesprächen.

ACR, Prüfübersicht und die drei Erklärungen bestehen axe (0 Verstöße) und den Nu Html Checker (0 Fehler). Das PDF ist getaggt, mit Überschriften, Tabellen, Lesezeichen und hinterlegter Sprache, aber nicht gegen PDF/UA validiert. Die Word-Datei nutzt echte Überschriften-Formatvorlagen, und ihre 13 Tabellen haben sich wiederholende Kopfzeilen.

Der ACR ist englischsprachig. Die Erklärungen liegen auf Türkisch, Englisch und Deutsch vor. Die Oberfläche der Anwendung ist türkisch. Firma, Produkt und Kontaktdaten sind fiktiv; in den Erklärungen sind die Angaben, die ein echter Hersteller ausfüllen muss, als Platzhalter belassen.

Sie erhalten einen ACR, den Sie einem Auftraggeber schicken können, die Prüfnachweise dahinter und bei Bedarf einen Erklärungsentwurf, der dasselbe sagt.

• Den ACR in VPAT 2.5 Rev INT als HTML, getaggtes PDF und Word. Er nennt Produktversion, Datum, Umfang, Methoden und deren Grenzen und enthält eine Bemerkung in jeder Zeile.
• Den Prüfbericht: Befunde mit Kriterium, Element und Korrekturvorschlag, Rohergebnisse von axe und der Skriptprüfungen, bei einem Nachtest vorher und nachher.
• Einen Entwurf der Erklärung zur Barrierefreiheit auf Deutsch, Englisch oder Türkisch. Die Angaben, die nur Sie machen können, sind klar markiert: Kontakt, Antwortfrist, zuständige Behörde und Termine für Korrekturen.
• Bei vereinbartem Nachtest einen aktualisierten ACR nach Ihren Korrekturen, der die Version beschreibt, die Sie tatsächlich ausliefern.

Sie senden zuerst einen Link; Umfang und Preis stehen fest, bevor die Prüfung beginnt.

1. Senden Sie einen Link. Einen Testzugang zum Produkt und den Fragebogen oder die Ausschreibungsklausel, die den Bericht verlangt. Ich sage Ihnen, was die ersten Ansichten zeigen und welche Standards der Auftraggeber tatsächlich fordert.
2. Sie erhalten Umfang und Festpreis: welche Ansichten, Abläufe und UI-Zustände, welche Standards, welche Berichtssprachen und ob ein Nachtest enthalten ist.
3. Ich führe die Prüfung durch. Sie erhalten die Befunde und einen ACR-Entwurf, auf jeder Seite als „DRAFT“ gekennzeichnet. Ihr Entwicklungsteam behebt, was Sie entscheiden; ist ein Nachtest vereinbart, prüfe ich erneut.
4. Ihre Freigabe gibt die endgültigen Dateien frei: den ACR in drei Formaten, den Prüfbericht und die Erklärung. Sie veröffentlichen sie unter dem Namen Ihres Unternehmens.

Ich kalkuliere jeden Auftrag, nachdem ich das Produkt gesehen habe. Der Aufwand hängt von der Zahl der Ansichten, Abläufe und Zustände ab und davon, ob eine Nachtestrunde enthalten ist, nicht davon, wie viele Kriterien die Vorlage auflistet. Sie erhalten vor Beginn einen Festpreis, ohne Stundenzähler.

Öffentliche Auftraggeber in der EU und in den USA müssen Barrierefreiheit beim Einkauf von Software berücksichtigen, und seit dem 28. Juni 2025 gelten BFSG und BaFG für viele Dienstleistungen an Verbraucher. Was das für Ihr Unternehmen bedeutet, ist eine Rechtsfrage; diese Seite behandelt die technische Seite.

Rechtlicher Hinweis: Diese Seite ist keine Rechtsberatung. Ob eine Vorschrift für Ihr Produkt gilt und wer in Ihrer Lieferkette die Pflicht trägt, klärt Ihre Rechtsberatung.

• Öffentliche Vergabe: Nach § 121 Abs. 2 GWB sind bei Leistungen, die zur Nutzung durch natürliche Personen vorgesehen sind, die Zugänglichkeitskriterien für Menschen mit Behinderungen in der Leistungsbeschreibung zu berücksichtigen, außer in ordnungsgemäß begründeten Fällen. Das setzt Artikel 42 Absatz 1 der Richtlinie 2014/24/EU um. Ausschreibungen nennen meist EN 301 549 V3.2.1, die im Durchführungsbeschluss (EU) 2021/1339 zitierte Norm.
• BFSG: Das Barrierefreiheitsstärkungsgesetz setzt den European Accessibility Act, Richtlinie (EU) 2019/882, um und gilt seit dem 28. Juni 2025, etwa für den elektronischen Geschäftsverkehr und Bankdienstleistungen für Verbraucher. Dienstleistungserbringer müssen nach § 14 und Anlage 3 BFSG Informationen dazu bereitstellen, wie ihre Dienstleistung die Anforderungen erfüllt. Die Erklärung im Beispiel folgt der EU-Mustererklärung aus dem Durchführungsbeschluss (EU) 2018/1523, die für öffentliche Stellen geschrieben ist und hier angepasst wurde.
• Österreich: Das Barrierefreiheitsgesetz (BaFG) setzt dieselbe Richtlinie um und gilt ebenfalls für Produkte und Dienstleistungen ab dem 28. Juni 2025.
• Öffentliche Stellen als Kunden: Entwickeln Sie Websites oder Apps für Behörden, müssen diese nach der Richtlinie (EU) 2016/2102, in Deutschland für Bundesstellen umgesetzt durch die BITV 2.0, eine Erklärung zur Barrierefreiheit veröffentlichen. Die Fakten dafür werden sie bei Ihnen erfragen.
• USA: Die Revised Section 508 Standards gelten für IKT, die US-Bundesbehörden beschaffen, und übernehmen für Web-Inhalte WCAG 2.0 AA. Behörden verlangen von Herstellern einen ACR für Marktrecherche und Bewertung; Section508.gov veröffentlicht dazu Hinweise für Behörden und Anbieter. Die ADA-Title-II-Regel für Bundesstaaten und Kommunen gilt nach der Verlängerung vom April 2026 ab 26. April 2027 (ab 50.000 Einwohnern) bzw. 26. April 2028 (kleinere Stellen), Maßstab WCAG 2.1 AA.

VPAT® ist eine eingetragene Marke des Information Technology Industry Council (ITI). Ich stehe in keiner Verbindung zum ITI. Meine Berichte folgen dem Aufbau von VPAT 2.5 Rev INT in eigenen Worten.

Das VPAT® ist die leere Vorlage, die das ITI veröffentlicht; ein ACR ist der ausgefüllte Bericht für eine Version eines Produkts. Einkäufer sagen oft „VPAT“, wenn sie den ausgefüllten Bericht meinen. Was sie von Ihnen brauchen, ist der ACR.

Nein. Er ist eine Selbsterklärung des Herstellers über das eigene Produkt, und Ihr Unternehmen veröffentlicht ihn unter eigenem Namen. Eine offizielle VPAT-Zertifizierung gibt es nicht. Glaubwürdig wird ein ACR dadurch, dass die Methoden genannt sind und sich jede Aussage auf einen Test oder auf den Code zurückführen lässt.

Sie deckt WCAG 2.2, EN 301 549 und die Revised Section 508 Standards in einem Dokument ab; derselbe Bericht kann an eine US-Behörde gehen und einer EU-Ausschreibung beiliegen. Fragen Ihre Auftraggeber immer nur nach einem Standard, genügt eine Ausgabe für diesen einen, und das sage ich Ihnen.

Nur dort, wo die Belege es tragen. Im Beispiel hat Version 1.1 weiterhin ein Does Not Support (2.2.1, eine 15-Minuten-Sitzung, die ohne Warnung endet) und zwei Partially Supports (1.4.11, eine Diagrammfarbe mit 1,81:1, sowie EN 301 549 12.2.3, Support ohne Gebärdensprach- oder Vermittlungsangebot). Erfahrene Prüfer vertrauen einem Bericht mit ehrlichen Lücken mehr als einer Spalte mit lauter gleichen Antworten.

Standardmäßig nicht. Zugängliche Namen werden aus dem Barrierefreiheitsbaum des Browsers gelesen; das zeigt, was ein Screenreader erhalten kann, nicht, was er ansagt. Verlangt ein Auftraggeber Tests mit NVDA, JAWS oder VoiceOver, lassen sie sich in den Umfang aufnehmen, und der ACR nennt dann, was wie getestet wurde.

Nein, das macht Ihr Entwicklungsteam. Ich liefere jeden Befund mit Kriterium, Element und Korrekturvorschlag und prüfe die ausgelieferte Version erneut, wenn das vereinbart ist. Im Beispiel habe ich die Demo-Anwendung nur deshalb selbst korrigiert, weil ich sie geschrieben hatte.

Das hängt davon ab, ob Ihr Produkt unter BFSG oder BaFG fällt oder Teil eines Auftrags für eine öffentliche Stelle ist, und das klärt Ihre Rechtsberatung. Brauchen Sie eine, entwerfe ich sie aus derselben Prüfung, damit Erklärung und ACR dasselbe sagen.

• Barrierefreie PDF (PDF/UA)
• Barrierefreie Word- und PowerPoint-Dokumente
• Barrierefreies Excel
• Barrierefreie E-Mails und Newsletter
• Barrierefreie Diagramme und Infografiken
• Barrierefreie Farbpalette
• Alternativtexte und Bildbeschreibung
• Übersetzung in Leichte Sprache

Einen Link zu Ihrem Produkt und den Fragebogen oder die Ausschreibungsklausel, die den Bericht verlangt. Sie erhalten eine klare Auskunft, was die ersten Ansichten zeigen und was der Auftraggeber tatsächlich von Ihnen braucht.

Ali Karabüyük · Tekirdağ, Türkei · arbeitet remote mit Kundinnen und Kunden weltweit · Dokument- und Bildproduktion seit 2004, beruflich seit 2008.