Drücke "Enter", um den Text zu überspringen.

volontary Product Accessibility Template – was man wissen muss

Heute möchte ich euch das VPAT vorstellen – das Voluntary Product Accessibility Template. Dabei handelt es sich um ein standardisiertes Dokument, mit dem Unternehmen die Barrierefreiheit ihrer Produkte transparent nachweisen können. Es ist somit vor allem für diejenigen interessant, die sich mit Prüfberichten, Nachweisen zur Barrierefreiheit und Zertifizierungen beschäftigen.

Wie ihr wahrscheinlich wisst, gibt es kein offizielles, allgemeingültiges „Zertifikat“ für Barrierefreiheit. Stattdessen existieren Prüfberichte und oft von einzelnen Anbietern selbst erstellte Zertifikate. Persönlich halte ich von Letzteren eher wenig. Das VPAT ist hingegen sehr hilfreich, weil es einen einheitlichen, klar strukturierten Standard bietet, um Informationen zur Barrierefreiheit darzustellen.

Herkunft und Lizenzierung des VPAT

Herausgegeben wird das VPAT vom US-amerikanischen Information Technology Industry Council (ITI). Obwohl es sich also um ein US-amerikanisches Dokument handelt, ist es lizenzfrei nutzbar. Man muss somit kein Geld bezahlen, um ein VPAT zu erstellen oder einzusetzen.

Das unterscheidet es beispielsweise von manchen Prüfverfahren wie dem BITV-Test, bei dem kommerzielle Nutzungen oder Zertifizierungen an bestimmte Verbandsmitgliedschaften oder Lizenzgebühren gebunden sein können. Ein VPAT hingegen darf jede Person und jede Organisation frei anbieten und ausfüllen.

Für welche Produkte eignet sich das VPAT?

Generell lässt sich sagen, dass ein VPAT eher für komplexe Produkte gedacht ist – beispielsweise für Single-Page-Webanwendungen, Desktop-Software oder umfangreiche mobile Apps. Für gewöhnliche, rein inhaltsgetriebene Websites ist es meist weniger geeignet.

Daraus folgt auch, dass keineswegs jedes Unternehmen zwingend ein VPAT erstellen muss. Marktüberwachungs- und Überwachungsstellen verlangen in der Regel eher klassische Prüfberichte bzw. deren Kernauswertungen. Bürgerinnen und Bürger wiederum erwarten eine leicht verständliche Erklärung zur Barrierefreiheit, in der bekannte Hürden übersichtlich aufgeführt sind.

Das VPAT erfüllt daher einen sehr speziellen Einsatzzweck: Es richtet sich primär an B2B-Einkäuferinnen und -Einkäufer von Software. Wenn beispielsweise ein Unternehmen eine Software von euch erwerben möchte und dafür einen Nachweis über die Barrierefreiheit benötigt, ist ein VPAT das Mittel der Wahl.

VPAT vs. ACR: Wie heißt das Dokument richtig?

Was genau ist das VPAT also? Das Voluntary Product Accessibility Template ist – wie der Name schon sagt – lediglich die leere Vorlage bzw. Struktur für den Bericht.

Sobald dieses Formular konkret für ein Produkt ausgefüllt wurde, bezeichnet man das finale Dokument offiziell als ACR (Accessibility Conformance Report). In der Praxis hat sich dieser Begriff jedoch kaum durchgesetzt. Wenn man online nach der Barrierefreiheit bestimmter Produkte sucht (z. B. „VPAT Google“), wird man fast immer unter der Bezeichnung VPAT fündig. Obwohl es korrekterweise ACR heißt, nutzt die Branche nahezu durchgängig den Begriff VPAT.

Die verschiedenen Versionen („Geschmacksrichtungen“)

Aktuell existieren drei bis vier Ausprägungen des VPATs, die auf unterschiedliche gesetzliche Rahmenbedingungen zugeschnitten sind:

  • Section 508: Basiert auf der Gesetzgebung der US-amerikanischen Bundesbehörden (inhaltlich sehr nah an der europäischen EN 301 549).
  • WCAG: Konzentriert sich rein auf die Richtlinien für barrierefreie Webinhalte in verschiedenen Versionen.
  • EN 301 549: Speziell auf die europäischen Standards und Richtlinien zugeschnitten. Das ist auch der Grund, warum das VPAT für den europäischen Markt immer relevanter wird.
  • INT (International): Eine umfassende Version, die alle Standards vereint (Section 508, WCAG und EN 301 549).

Besonders internationale Konzerne wie Google oder Microsoft stellen ihre VPATs in der Regel in der INT-Version bereit, da sie damit weltweit alle Märkte auf einmal abdecken können.

Aufbau und Bewertungskriterien des VPATs

Visuell ist das Dokument recht schlicht gehalten. Es beginnt mit den üblichen Basisinformationen: Was ist das für ein Produkt? Wer ist der Anbieter? Wann wurde getestet? Der Hauptteil besteht aus einer sehr ausführlichen Tabelle, in der alle einzelnen Kriterien aufgelistet und bewertet werden.

Für die Bewertung kommt ein festgelegtes Vokabular zum Einsatz:

  • Supports: Das Kriterium wird vollständig erfüllt.
  • Partially Supports: Das Kriterium wird teilweise erfüllt.
  • Not Supported: Das Kriterium wird nicht erfüllt.
  • Not Evaluated / Not Tested: Das Kriterium wurde nicht geprüft.
  • Not Applicable: Das Kriterium ist nicht anwendbar (z. B. Untertitel-Kriterien bei Produkten ohne Audio-/Video-Inhalte).

Der Fokus auf Konsequenzen und Workarounds

Eine wichtige Besonderheit des VPATs liegt in der Beschreibung der Abweichungen in der rechten Spalte der Tabelle: Hier geht es nicht nur darum, rein technische Fehler aufzuzählen (wie man es aus einem klassischen Prüfbericht kennt), sondern die konkreten Auswirkungen und Blocker für die Nutzerinnen und Nutzer zu beschreiben.

Anstatt also lediglich zu schreiben „Tastaturfokus wird auf Element XY nicht visuell hervorgehoben“, wird erklärt, welche praktische Konsequenz das hat – beispielsweise, dass ein bestimmtes Formular mit der Tastatur oder dem Screenreader nicht bedient werden kann.

Da sich das Dokument an Einkaufsabteilungen richtet, müssen die Angaben so aufbereitet sein, dass auch Nicht-Fachleute die Risiken einschätzen können:

  • Gibt es für ein Problem einen zumutbaren Umweg (Workaround)?
  • Handelt es sich um einen echten Blocker, der eine Kernfunktion unnutzbar macht?
  • Oder ist es lediglich eine kleine Einschränkung im Bedienkomfort?

Durch diese Transparenz können Verantwortliche im Einkauf direkt beurteilen, ob die Software den internen Richtlinien der Organisation entspricht und bedenkenlos angeschafft werden kann.

VPAT vs. Prüfbericht: Die wesentlichen Unterschiede

Schauen wir uns einmal den genauen Unterschied zwischen einem VPAT und einem klassischen Prüfbericht an:

Ein Prüfbericht listet sämtliche gefundenen Barrierefreiheitsfehler innerhalb einer Anwendung detailliert auf. Er beschreibt präzise, wie diese behoben werden können bzw. wie das erwünschte Soll-Verhalten aussieht. Damit richtet er sich speziell an technisch erfahrene Personen – also an Entwicklerinnen und Entwickler, die den Code lesen und reparieren können. Sie müssen nicht zwingend Barrierefreiheits-Profis sein, aber sie verstehen den technischen Hintergrund.

Das VPAT hingegen wendet sich gezielt an Einkäuferinnen und Einkäufer, die häufig technische Laien sind. Der Fokus eines Prüfberichts liegt auf der konkreten technischen Lösung eines Problems. Das VPAT beschreibt hingegen in allgemein verständlicher Sprache, worin die Einschränkung besteht und welche Auswirkung sie hat.

Daran wird auch deutlich: Der Prüfbericht bildet im Grunde die fachliche Basis für das VPAT. Wir benötigen stets einen fundierten Prüfbericht nach einer sauberen Prüfmethodik. Dessen Ergebnisse müssen anschließend für die Zielgruppe im Einkauf übersetzt werden.

Der Fokus: Konsequenzen statt Code-Details

In der rechten Spalte des VPATs („Remarks and Explanations“) wird erläutert, was konkret nicht funktioniert und welche Konsequenz sich daraus für die Nutzung ergibt – etwa ob eine Person mit einer bestimmten Behinderung die Anwendung dadurch gar nicht oder nur eingeschränkt nutzen kann.

Das ist auch der Grund, warum sehr einfache Produkte kein VPAT benötigen. Für eine reine Content-Website oder eine einfache App mit Kontaktformular braucht man in der Regel kein VPAT, da dort selten komplexe funktionale Hürden existieren, die jemanden vollständig von der Nutzung ausschließen.

Marktentwicklung: Warum auch deutsche Anbieter umdenken müssen

Aktuell ist das VPAT in Deutschland noch vergleichsweise unbekannt. Bisher wird es fast ausschließlich von US-amerikanischen oder großen internationalen Konzernen eingesetzt (SAP bildet hier eine der wenigen deutschen Ausnahmen). Doch der Compliance-Druck auf IT-Anbieter wächst kontinuierlich.

Einkaufsabteilungen verlangen zunehmend Transparenz über die Barrierefreiheit von Fachanwendungen oder Vertragssystemen. Ein rein technischer Prüfbericht hilft im Einkauf jedoch nicht weiter, da er ohne Fachwissen schwer zu interpretieren ist. Die entscheidende Frage für Verantwortliche lautet nämlich: Handelt es sich um einen kritischen Blocker oder lediglich um einen verkraftbaren Schönheitsfehler?

Warum Zertifikate nicht ausreichen

Statische Zertifikate sind in der modernen Softwareentwicklung oft wenig aussagekräftig. Anwendungen verändern sich heute rasend schnell. Wenn beispielsweise unter der Haube ein UI-Framework ausgetauscht wird, sieht die Oberfläche optisch identisch aus, aber die Barrierefreiheit kann von einem Tag auf den anderen komplett zerstört sein. Ein ein Jahr altes Zertifikat bietet in solchen Fällen keinerlei Sicherheit.

Praxisbeispiel: Bei einem Content-Management-System wurde im Zuge eines Hauptversions-Updates die zugrunde liegende UI-Bibliothek ausgetauscht. Obwohl das System zuvor als WCAG-konform beworben wurde, war die neue Version für Menschen mit Behinderungen schlichtweg unbedienbar.

Die Notwendigkeit eines verbindlichen Maßnahmenplans

Ein VPAT ist eine Momentaufnahme. Es belegt nicht automatisch, dass ein Produkt perfekt barrierefrei ist, und es garantiert auch nicht, dass aktiv daran gearbeitet wird. Ein rein statisches Dokument reicht daher nicht aus.

Unternehmen im IT-Sektor sollten daher eine klare Strategie verfolgen:

  • Regelmäßige Tests durchführen und das VPAT (mindestens einmal jährlich) aktualisieren.
  • Einen verbindlichen Maßnahmen- und Zeitplan etablieren, der aufzeigt, wie bestehende Barrieren sukzessive abgebaut und neue verhindert werden.

Wenn ich Einkaufsabteilungen berate, empfehle ich stets, von Dienstleistern genau diesen Fahrplan einzufordern – inklusive einer Rückschau auf die Fortschritte der letzten ein bis zwei Jahre.

Fazit: Barrierefreiheit als strategischer Wettbewerbsvorteil

Viele IT-Anbieter im B2B-Bereich wie auch bei Fachverfahren wähnten sich lange Zeit durch Monopolstellungen geschützt. Dieser Markt wandelt sich jedoch spürbar. Die gesetzlichen und organisatorischen Anforderungen an Barrierefreiheit steigen drastisch.

Ein VPAT in Kombination mit einem klaren Maßnahmenplan ist heute kein optionales Extra mehr, sondern ein entscheidendes Kriterium im Beschaffungsprozess. Je früher sich Unternehmen mit dieser Systematik auseinandersetzen, desto besser sind sie für die Zukunft aufgestellt.