Barrierefreiheit im SaaS-Vertrag: VPAT, EN 301 549 und Nachbesserung verbindlich regeln

Eine Fachabteilung möchte eine neue SaaS-Anwendung einführen. Im Auswahlverfahren zeigt der Anbieter einen VPAT-Bericht, die Oberfläche wirkt auf den ersten Blick modern und zugänglich. Nach dem Go-live stellt sich jedoch heraus: Formularfelder sind für Screenreader nicht eindeutig beschriftet, wichtige Statusmeldungen werden nicht vorgelesen und die Tastaturbedienung bricht in einem zentralen Freigabeprozess ab. Der Anbieter verweist auf geplante Releases. Für dein Unternehmen ist das zu spät, insbesondere wenn Mitarbeitende, Kunden oder Geschäftspartner die Anwendung tatsächlich nutzen müssen.

Digitale Barrierefreiheit ist deshalb nicht nur ein Qualitätsmerkmal. Sie ist ein Beschaffungs-, Compliance- und Haftungsthema. Seit dem 28. Juni 2025 gelten mit dem Barrierefreiheitsstärkungsgesetz zusätzliche Anforderungen für bestimmte Produkte und Dienstleistungen im Verbrauchergeschäft. Ob eine konkrete SaaS-Leistung unmittelbar erfasst ist, hängt vom Geschäftsmodell, den Nutzern und der Funktion des Dienstes ab. Auch wenn dein Unternehmen nicht direkt in den Anwendungsbereich fällt, entstehen Risiken aus Kundenanforderungen, öffentlichen Auftraggebern, internen Gleichbehandlungspflichten und der praktischen Nutzbarkeit.

Im SaaS-Vertrag solltest du Barrierefreiheit daher nicht als unverbindliche Produktzusage behandeln. Entscheidend sind ein klarer Sollzustand, belastbare Nachweise, nachvollziehbare Prüfungen und verbindliche Regeln zur Mängelbeseitigung.

Infografik zu Barrierefreiheit im SaaS-Vertrag: VPAT, EN 301 549 und Nachbesserung verbindlich regeln (KI-generiert).

Zuerst klären: Für welche Nutzung beschaffst du die Software?

Die Vertragsanforderungen hängen davon ab, wer die SaaS-Anwendung nutzt und welche Aufgaben damit erledigt werden. Eine interne Anwendung für wenige spezialisierte Administratoren ist anders zu bewerten als ein Kundenportal, ein Online-Shop, eine Buchungsstrecke oder eine digitale Kommunikationsplattform.

Kläre vor der Ausschreibung mindestens diese Punkte:

• Ist die Anwendung für Verbraucher, Beschäftigte, Kunden, Lieferanten oder die Öffentlichkeit bestimmt?
• Gibt es Funktionen, die ohne Maus, mit Screenreader, mit Vergrößerungssoftware oder per Spracheingabe bedienbar sein müssen?
• Werden zentrale Geschäftsprozesse vollständig in der Anwendung abgewickelt?
• Welche Inhalte stammen vom Anbieter, welche erstellt dein Unternehmen selbst?
• Gibt es mobile Apps, eingebettete Widgets, PDF-Dokumente, E-Mails oder Schnittstellen, die zum Nutzungserlebnis gehören?
• Welche gesetzlichen, branchenspezifischen oder vertraglichen Anforderungen gelten für dein Unternehmen?

Diese Vorarbeit verhindert einen häufigen Fehler: Der Anbieter sagt Barrierefreiheit für seine Standardoberfläche zu, während dein Unternehmen annimmt, dass damit auch Vorlagen, individuelle Konfigurationen, Schnittstellen oder eingebundene Drittinhalte abgedeckt sind.

Formuliere daher im Vertrag ausdrücklich, welche Bestandteile zur geschuldeten Leistung gehören. Dazu zählen je nach Produkt Weboberfläche, mobile Anwendung, Hilfedokumentation, E-Mail-Benachrichtigungen, PDF-Ausgaben, Integrationen und Funktionen zur Inhaltserstellung.

EN 301 549 als Vertragsmaßstab richtig einsetzen

Die europäische Norm EN 301 549 beschreibt Anforderungen an die Barrierefreiheit von Informations- und Kommunikationstechnik. Sie verweist für Webinhalte und Software in wesentlichen Teilen auf die Web Content Accessibility Guidelines, kurz WCAG. Für SaaS-Anwendungen ist sie ein sinnvoller Ausgangspunkt, weil sie nicht nur die sichtbare Oberfläche betrachtet, sondern auch Dokumentation, Support und unterschiedliche Nutzungsarten einbezieht.

Im Vertrag genügt allerdings keine knappe Formulierung wie: „Die Software ist barrierefrei nach EN 301 549.“ Sie lässt offen, welche Normfassung gilt, welche Teile der Norm einschlägig sind, ob Ausnahmen bestehen und wie die Einhaltung geprüft wird.

Besser ist eine präzise Leistungsbeschreibung. Sie sollte insbesondere festhalten:

Vertragsfrage	Praxisfeste Regelung
Maßstab	Benenne die konkrete Fassung der EN 301 549 und die einschlägigen WCAG-Erfolgskriterien.
Geltungsbereich	Liste alle vereinbarten Module, Oberflächen, Apps, Dokumentationen und eingebundenen Komponenten auf.
Konformitätsniveau	Bestimme, welches Niveau für die relevanten Webinhalte und Funktionen geschuldet ist.
Ausnahmen	Dokumentiere jede Ausnahme einzeln, begründe sie und lege eine Abhilfemaßnahme fest.
Änderungen	Verpflichte den Anbieter, die Konformität auch bei Releases, Updates und neuen Modulen zu erhalten.
Nachweise	Lege fest, welche Berichte, Testprotokolle und Erklärungen der Anbieter in welchen Abständen liefert.

Achte darauf, dass eine Norm nicht blind vollständig übernommen wird. Manche Anforderungen sind für deine konkrete Anwendung nicht relevant. Andere können über die Norm hinaus erforderlich sein, etwa wenn Nutzer mit bestimmten assistiven Technologien arbeiten. Genau diese Abgrenzung gehört in den Vertrag oder in eine verbindliche Anlage.

VPAT ist ein Nachweis, aber keine Abnahme

Ein VPAT, also ein Voluntary Product Accessibility Template, ist ein verbreitetes Dokumentationsformat. Anbieter beschreiben darin, wie ihr Produkt bestimmte Anforderungen erfüllt. Der daraus erstellte Bericht wird häufig als Accessibility Conformance Report bezeichnet.

Für die Beschaffung ist ein VPAT nützlich, weil du Anbieter vergleichbar befragen kannst. Er ersetzt aber weder eine technische Prüfung noch eine vertragliche Zusage. Ein VPAT ist häufig eine Selbstauskunft. Seine Aussagekraft hängt davon ab, wie aktuell er ist, welche Produktversion er abdeckt, welche Tests durchgeführt wurden und ob Abweichungen nachvollziehbar beschrieben sind.

Fordere deshalb nicht nur „einen VPAT“ an, sondern prüfe seine Qualität anhand konkreter Fragen:

• Bezieht sich der Bericht auf die tatsächlich angebotene Produktversion?
• Sind alle von dir beschafften Module und Apps erfasst?
• Wird zu jeder Anforderung verständlich erläutert, wie sie erfüllt wird?
• Sind bekannte Einschränkungen konkret benannt?
• Enthält der Bericht Angaben zu Testmethoden, Testwerkzeugen und eingesetzten assistiven Technologien?
• Wurde der Bericht durch unabhängige Stellen geprüft oder nur vom Anbieter erstellt?
• Gibt es eine Roadmap mit Terminen für erkannte Lücken?

Ein guter Vertrag verpflichtet den Anbieter, den VPAT oder einen gleichwertigen Konformitätsbericht vor Vertragsbeginn vorzulegen und bei wesentlichen Änderungen zu aktualisieren. Wesentlich kann ein neues Hauptmodul, ein umfangreiches Redesign oder eine Änderung der Bedienlogik sein. Definiere diesen Begriff möglichst konkret.

Prüfungen vor und nach dem Go-live vereinbaren

Barrierefreiheit lässt sich nicht allein durch automatisierte Werkzeuge feststellen. Solche Tests erkennen zwar viele technische Fehler, aber nicht, ob eine komplexe Prozessführung verständlich oder eine Fehlermeldung im richtigen Moment wahrnehmbar ist. Deshalb brauchst du ein abgestuftes Prüfkonzept.

Vor der Abnahme oder Produktivsetzung sollte ein Test mindestens die geschäftskritischen Nutzerwege abdecken. Dazu gehören beispielsweise Registrierung, Anmeldung, Suche, Dateneingabe, Genehmigung, Zahlung, Download und Supportkontakt. Welche Wege relevant sind, richtet sich nach deiner Anwendung.

Vereinbare folgende Prüfbausteine:

• Automatisierte Prüfungen für wiederkehrende technische Anforderungen.
• Manuelle Fachprüfung anhand der vereinbarten Normanforderungen.
• Tastaturtests ohne Maus.
• Tests mit gängigen Screenreadern und den für deine Zielgruppe relevanten Browsern und Betriebssystemen.
• Prüfung bei Vergrößerung, hohem Kontrast und unterschiedlichen Bildschirmgrößen.
• Nutzertests mit Menschen mit Behinderungen, wenn die Anwendung besonders kritisch oder öffentlich zugänglich ist.

Der Vertrag sollte außerdem regeln, wer testet, wer die Kosten trägt und welche Unterlagen der Anbieter bereitstellt. Dazu können Testzugänge, Testdaten, Release Notes, eine Liste bekannter Einschränkungen und Ansprechpartner aus Produktentwicklung oder Qualitätssicherung gehören.

Wichtig ist die Rechtsfolge. Wird ein kritischer Nutzerweg nicht barrierefrei erfüllt, darf dies nicht lediglich als Hinweis im Abnahmeprotokoll stehen bleiben. Definiere, wann ein Befund ein Mangel ist und wann eine Abnahme verweigert werden kann.

Nachbesserung mit Fristen und Prioritäten verbindlich machen

Bei SaaS ist Barrierefreiheit eine dauerhafte Leistungspflicht. Ein einmal getestetes Release kann durch ein späteres Update neue Barrieren schaffen. Deshalb sollten Nachbesserung und Änderungsmanagement zusammen geregelt werden.

In der Praxis bewährt sich eine Mängelklassifizierung. Sie orientiert sich nicht allein an der technischen Ursache, sondern vor allem an der Auswirkung auf Nutzer und Geschäftsprozess.

Priorität	Typischer Fall	Vertragliche Folge
Kritisch	Ein zentraler Prozess ist für Tastatur- oder Screenreader-Nutzer nicht nutzbar.	Unverzügliche Analyse, kurzfristige Abhilfe oder wirksame Umgehungslösung.
Hoch	Eine wesentliche Funktion ist nur erheblich erschwert nutzbar.	Verbindlicher Korrekturtermin im nächsten geeigneten Release.
Mittel	Die Nutzung ist möglich, aber Informationen oder Bedienung sind fehlerhaft.	Behebung innerhalb eines vereinbarten Wartungszyklus.
Niedrig	Geringe Beeinträchtigung ohne Auswirkungen auf Kernprozesse.	Aufnahme in die priorisierte Produktplanung mit Transparenz zum Status.

Konkrete Fristen müssen zu deinem Risiko und zum Release-Modell des Anbieters passen. Eine pauschale Frist für jeden Fehler ist selten sinnvoll. Entscheidend ist, dass der Anbieter nicht nur „angemessene Bemühungen“ schuldet, sondern die Behebung oder eine gleichwertige, barrierefreie Alternative verbindlich leisten muss.

Regle auch, was als Umgehungslösung akzeptiert wird. Ein PDF mit manuellen Anweisungen oder ein Supportkanal, der nur zu Geschäftszeiten erreichbar ist, ersetzt nicht automatisch eine zugängliche Kernfunktion. Eine Übergangslösung muss praktisch nutzbar, barrierefrei und zeitlich begrenzt sein.

Haftung und Gewährleistung nicht hinter allgemeinen Klauseln verstecken

Viele SaaS-Verträge enthalten weitreichende Haftungsbegrenzungen. Das ist im B2B-Bereich grundsätzlich üblich. Wenn Barrierefreiheit für deine Leistungserbringung wesentlich ist, darf sie darin aber nicht unsichtbar werden.

Prüfe besonders diese Punkte:

• Ist die Einhaltung der vereinbarten Anforderungen ausdrücklich als Beschaffenheit der SaaS-Leistung definiert?
• Gelten Verstöße als Mangel und nicht nur als unverbindlicher Verbesserungswunsch?
• Welche Rechte hast du, wenn der Anbieter nicht fristgerecht nachbessert?
• Kannst du Zahlungen angemessen zurückhalten, Leistungen mindern oder bei erheblichen Mängeln kündigen?
• Trägt der Anbieter die Kosten der erneuten Prüfung nach einer Nachbesserung?
• Wie werden Ansprüche Dritter, Beschwerden von Kunden oder behördliche Maßnahmen behandelt, soweit sie auf einem vom Anbieter verursachten Mangel beruhen?
• Bleiben zwingende gesetzliche Haftungsregeln von Haftungsbegrenzungen unberührt?

Eine Freistellung durch den Anbieter kann sinnvoll sein, wenn dein Unternehmen wegen einer von ihm zu vertretenden Barriere gegen Ansprüche Dritter verteidigen muss. Sie sollte jedoch sauber abgegrenzt werden. Der Anbieter kann nicht für Barrieren haften, die ausschließlich durch Inhalte, Konfigurationen oder Eigenentwicklungen deines Unternehmens entstehen. Umgekehrt darf er sich nicht pauschal auf „Kundeninhalte“ berufen, wenn sein Editor oder sein Vorlagensystem selbst keine zugängliche Inhaltserstellung ermöglicht.

Verantwortlichkeiten im Betrieb festlegen

Auch ein sehr guter SaaS-Vertrag löst nicht jede Aufgabe beim Anbieter. Dein Unternehmen erstellt Inhalte, vergibt Rollen, konfiguriert Workflows und entscheidet über eingebundene Systeme. Dokumentiere deshalb eine klare Verantwortungsmatrix.

Der Anbieter sollte für die barrierefreie Standardplattform, die vereinbarten Funktionen, Updates und seine Dokumentation einstehen. Dein Unternehmen verantwortet typischerweise eigene Inhalte und Konfigurationen. Bei gemeinsam beeinflussten Bereichen, etwa Formularvorlagen oder Designsystemen, brauchst du Schulungen, Prüfroutinen und verbindliche Freigaben.

Lege außerdem fest, wie Barrieren gemeldet werden. Ein zugänglicher Meldeweg, feste Ansprechpartner, Ticketkategorien und nachvollziehbare Statusinformationen helfen, Probleme früh zu bearbeiten. Passende Seminare und Termine findest du bei uns auf cmt.de.

Checkliste für die Vertragsverhandlung

Bevor du einen SaaS-Vertrag unterschreibst, solltest du diese Punkte abhaken:

• Der sachliche und technische Geltungsbereich der Barrierefreiheit ist vollständig beschrieben.
• Die maßgebliche Fassung der EN 301 549 und ergänzende Anforderungen sind benannt.
• Der Anbieter legt einen aktuellen, produktbezogenen VPAT oder gleichwertigen Bericht vor.
• Bekannte Abweichungen sind transparent dokumentiert und mit verbindlichen Maßnahmen versehen.
• Kritische Nutzerwege werden vor dem Go-live geprüft.
• Updates dürfen die vereinbarte Konformität nicht verschlechtern.
• Mängelprioritäten, Reaktionszeiten, Behebungsfristen und Eskalationen sind geregelt.
• Nachbesserung ist eine geschuldete Leistung, nicht nur ein unverbindlicher Plan.
• Abnahme, Gewährleistung, Kündigungsrechte und Haftungsregelungen passen zur Bedeutung der Anwendung.
• Verantwortlichkeiten für Inhalte, Konfigurationen und Drittintegrationen sind eindeutig zugeordnet.

So wird Barrierefreiheit vom allgemeinen Produktversprechen zu einer überprüfbaren Vertragspflicht. Das schützt nicht nur vor rechtlichen und wirtschaftlichen Risiken. Vor allem stellst du sicher, dass die beschaffte SaaS-Anwendung für die Menschen funktioniert, die sie täglich einsetzen sollen.