Barrierefreie Software beschaffen: BITV 2.0 und EN 301 549 in der Ausschreibung

Eine neue Fachanwendung steht kurz vor der Ausschreibung. Die Oberfläche soll von Mitarbeitenden, Bürgerinnen und Bürgern sowie externen Stellen genutzt werden. Im Entwurf der Leistungsbeschreibung findet sich bisher nur ein Satz: „Die Software muss barrierefrei sein.“ Das klingt richtig, ist aber vergaberechtlich und technisch zu unbestimmt. Was genau muss der Auftragnehmer liefern? Welche Norm gilt? Wie wird die Anforderung bewertet und wann gilt sie als erfüllt?

Genau an diesen Punkten entscheidet sich, ob digitale Barrierefreiheit im Projekt tatsächlich ankommt oder erst nach dem Zuschlag als teure Nachforderung diskutiert wird. Wir zeigen dir, wie du BITV 2.0 und EN 301 549 für Websites, Apps und Fachverfahren prüfbar in deine Vergabeunterlagen integrierst.

Infografik zu Barrierefreie Software beschaffen: BITV 2.0 und EN 301 549 in der Ausschreibung (KI-generiert).

Den Rechtsrahmen richtig einordnen

Für öffentliche Stellen des Bundes ist die Barrierefreie-Informationstechnik-Verordnung, kurz BITV 2.0, ein zentraler Maßstab. Sie betrifft insbesondere Websites, mobile Anwendungen und weitere digitale Angebote der Bundesverwaltung. Für Länder und Kommunen gelten jeweils landesrechtliche Regelungen, die sich in Aufbau und Anforderungen unterscheiden können. Prüfe deshalb vor jeder Ausschreibung, welche Vorgaben für deine Organisation konkret gelten.

Die europäische Norm EN 301 549 übersetzt Anforderungen an die Barrierefreiheit von Informations- und Kommunikationstechnik in technische und prüfbare Kriterien. Sie umfasst nicht nur Webinhalte, sondern je nach Beschaffungsgegenstand auch Software, mobile Anwendungen, elektronische Dokumente, Hardware, Support und Dokumentation.

Das Barrierefreiheitsstärkungsgesetz, kurz BFSG, erhöht seit Juni 2025 insbesondere für bestimmte Produkte und Dienstleistungen im Verbrauchergeschäft den Umsetzungs- und Nachweisdruck. Es ersetzt aber nicht die BITV 2.0 und ist auch kein allgemeiner Beschaffungsmaßstab für jede öffentliche IT-Vergabe. Für deine Ausschreibung bedeutet das: Bestimme zuerst den rechtlichen Anwendungsbereich und lege dann vertraglich fest, welche Anforderungen für das konkrete System gelten sollen.

Eine Formulierung wie „Die Anwendung erfüllt EN 301 549“ genügt meist nicht. Die Norm enthält Anforderungen für unterschiedliche IKT-Arten. Für eine browserbasierte Fachanwendung sind andere Teile relevant als für eine mobile App, ein PDF-Formular oder eine Anwendung mit Videokommunikation.

Den Beschaffungsgegenstand in Nutzungsszenarien zerlegen

Barrierefreiheit lässt sich nicht allein anhand von Bildschirmseiten bewerten. Entscheidend sind die Aufgaben, die Menschen mit der Anwendung erledigen müssen. Beginne deshalb mit realen Nutzungsszenarien.

Bei einem Fachverfahren können das etwa Anmeldung, Suche, Datenerfassung, Bearbeitung, Freigabe, Bescheiderstellung, Export und Fehlerkorrektur sein. Bei einer Website gehören häufig Navigation, Formularübermittlung, Terminbuchung, Download von Dokumenten und Kontaktaufnahme dazu. Bei Apps sind zusätzlich Touch-Bedienung, Bildschirmorientierung, Systemschriftgrößen und die Zusammenarbeit mit mobilen Hilfstechnologien relevant.

Halte für jedes Szenario fest:

• Welche Nutzergruppen verwenden die Funktion?
• Welche Eingaben, Meldungen und Dokumente kommen vor?
• Ist die Aufgabe ausschließlich per Tastatur bedienbar?
• Welche Informationen werden visuell, akustisch oder über Farbe vermittelt?
• Welche technischen Komponenten sind beteiligt, etwa Weboberfläche, PDF-Ausgabe, Schnittstelle oder mobile App?
• Welche Teile liefert der Auftragnehmer, welche entstehen später durch Konfiguration oder Inhalte deiner Stelle?

Diese Vorarbeit verhindert einen häufigen Fehler: Die Oberfläche wird barrierefrei entwickelt, aber automatisch erzeugte PDF-Dokumente, E-Mails oder Fehlermeldungen bleiben unzugänglich.

Anforderungen konkret in die Leistungsbeschreibung aufnehmen

Die Leistungsbeschreibung ist der wichtigste Ort für verbindliche Barrierefreiheitsanforderungen. Sie muss so formuliert sein, dass Bietende ihren Aufwand einschätzen und du die Leistung später objektiv prüfen kannst.

Nenne die anzuwendende Fassung der EN 301 549 und grenze die einschlägigen Anforderungen passend zum Beschaffungsgegenstand ein. Bei Webanwendungen sind regelmäßig Anforderungen an Webinhalte und Software relevant. Bei mobilen Anwendungen kommen Anforderungen für mobile Nutzung und Plattformintegration hinzu. Werden Dokumente erzeugt oder bereitgestellt, müssen auch Anforderungen an nicht webbasierte Dokumente berücksichtigt werden.

Bereich	Prüffähige Anforderung
Tastaturbedienung	Alle Funktionen der Nutzeroberfläche sind ohne Maus vollständig bedienbar. Fokusreihenfolge und sichtbare Fokusanzeige unterstützen die Aufgabenbearbeitung.
Semantik	Bedienelemente, Überschriften, Tabellen, Statusmeldungen und Fehlermeldungen sind programmatisch ermittelbar und für Hilfstechnologien verständlich ausgegeben.
Formulare	Pflichtfelder, Eingabeformate und Fehler werden verständlich bezeichnet. Fehlerhinweise sind auffindbar und einer Korrekturmöglichkeit zugeordnet.
Kontraste und Darstellung	Texte, Bedienelemente und Zustände erfüllen die einschlägigen Kontrastanforderungen. Informationen werden nicht allein durch Farbe vermittelt.
Zoom und Responsive Design	Die Anwendung bleibt bei vergrößerter Darstellung und unterschiedlichen Bildschirmgrößen nutzbar, ohne dass wesentliche Inhalte oder Funktionen verloren gehen.
Dokumente	Vom System erzeugte Dokumente und Vorlagen sind entsprechend ihrer vorgesehenen Nutzung barrierefrei strukturiert und mit Hilfstechnologien lesbar.
Support	Bedienungsanleitungen, Hilfeseiten und Supportprozesse sind selbst zugänglich und enthalten Hinweise zur barrierefreien Nutzung.

Vermeide dabei unbestimmte Begriffe wie „möglichst barrierearm“, „weitgehend zugänglich“ oder „nach aktuellem Stand“. Solche Formulierungen lassen offen, welche Leistung geschuldet ist. Besser ist eine Kombination aus Normbezug, konkreten Nutzungsszenarien und prüfbaren Akzeptanzkriterien.

Definiere außerdem, ob Anforderungen auch für Standardkomponenten, Updates, Erweiterungen und Konfigurationen gelten. Gerade bei Standardsoftware argumentieren Anbieter sonst gelegentlich, nur der unveränderte Kern sei Gegenstand des Nachweises. Für dich zählt jedoch die tatsächlich eingesetzte Lösung.

Eignung, Zuschlag und Vertragsbedingungen sauber trennen

Nicht jede Anforderung gehört an dieselbe Stelle in der Vergabe. Die saubere Zuordnung schützt vor unnötigen Nachprüfungsrisiken und verbessert die Vergleichbarkeit der Angebote.

Eignung: Erfahrung und Personal prüfen

Bei der Eignung prüfst du, ob ein Unternehmen den Auftrag grundsätzlich zuverlässig ausführen kann. Du kannst beispielsweise vergleichbare Referenzen verlangen, wenn barrierefreie Softwareentwicklung für den Auftrag wesentlich ist. Ebenso kannst du Qualifikationen der für Konzeption, Entwicklung und Qualitätssicherung vorgesehenen Personen abfragen.

Die Anforderungen müssen mit dem Auftragsgegenstand zusammenhängen und verhältnismäßig sein. Fordere nicht pauschal eine bestimmte Zertifizierung, wenn auch andere gleichwertige Nachweise die erforderliche Kompetenz belegen können. Aussagekräftig sind etwa Referenzbeschreibungen mit Angaben zu Testmethoden, eingesetzten Hilfstechnologien, behobenen Mängeln und der Rolle des Unternehmens im Projekt.

Zuschlagskriterien: Qualität bewertbar machen

Wenn Angebote bei der Barrierefreiheit unterschiedlich leistungsfähig sein können, solltest du die Qualität nicht allein als Mindestanforderung behandeln. Zuschlagskriterien ermöglichen es dir, bessere Konzepte nachvollziehbar zu bewerten.

Bewertbar sind zum Beispiel:

• das Vorgehen zur barrierefreien Konzeption und Entwicklung
• die Abdeckung deiner vorgegebenen Nutzungsszenarien
• ein Test- und Nachweiskonzept für Releases
• die Einbindung qualifizierter Prüferinnen und Prüfer
• die Qualität eines exemplarisch vorgelegten Bedien- oder Gestaltungskonzepts
• der Umgang mit bekannten Einschränkungen und geplanten Korrekturen

Lege in der Bewertungsmatrix offen, was eine gute, ausreichende oder schwache Leistung ausmacht. Ein Kriterium wie „Barrierefreiheit: 10 Punkte“ ohne Unterkriterien lädt zu subjektiver Wertung ein.

Vertragsbedingungen: Barrierefreiheit dauerhaft sichern

Barrierefreiheit endet nicht mit dem Go-live. Nimm deshalb Verpflichtungen für Fehlerbehebung, Updates, Change Requests und Dokumentation in den Vertrag auf. Der Auftragnehmer sollte bekannte Einschränkungen dokumentieren, Mängel klassifizieren und Korrekturen innerhalb vereinbarter Fristen bereitstellen.

Wichtig ist auch eine Regelung für Drittkomponenten. Wenn eine Bibliothek, ein Kartenmodul oder ein Identitätsdienst Einschränkungen verursacht, bleibt die Verantwortung für die vertraglich geschuldete Gesamtlösung nicht automatisch folgenlos. Kläre, wie der Auftragnehmer Alternativen, Workarounds oder Anpassungen nachweist.

Abnahme mit Testplan und belastbaren Nachweisen organisieren

Die Abnahme ist der Moment, in dem aus einer Anforderung eine überprüfte Lieferpflicht wird. Plane sie nicht erst kurz vor Projektende. Bereits in der Leistungsbeschreibung sollte stehen, welche Unterlagen und Tests erwartet werden.

Ein belastbares Abnahmekonzept enthält mindestens:

• eine Liste der zu prüfenden Nutzungsszenarien
• die jeweils relevanten Anforderungen der EN 301 549
• Angaben zu Testumgebung, Browsern, Betriebssystemen und mobilen Plattformen
• Prüfungen mit Tastatur und geeigneten Hilfstechnologien
• manuelle Prüfungen durch qualifizierte Personen
• nachvollziehbare Testprotokolle mit Fundstelle, Bewertung und Beleg
• eine Mängelliste mit Priorisierung, Verantwortlichkeit und Korrekturstatus
• eine Wiederholungsprüfung nach der Mängelbeseitigung

Automatisierte Tests sind sinnvoll, aber nicht ausreichend. Sie erkennen beispielsweise fehlende Alternativtexte, bestimmte Kontrastprobleme oder fehlerhafte technische Strukturen. Ob eine Fehlermeldung verständlich ist, ob die Fokusführung bei einem komplexen Dialog funktioniert oder ob ein Formular sinnvoll bedienbar bleibt, musst du zusätzlich manuell prüfen.

Verlange keinen bloßen Konformitätsvermerk ohne überprüfbare Grundlage. Ein „Accessibility Statement“ oder eine Eigenerklärung kann eine sinnvolle Dokumentation sein, ersetzt aber keine Abnahmeprüfung. Entscheidend sind Testfälle, Ergebnisse und die nachweisbare Behebung festgestellter Mängel.

Checkliste für deine nächste Ausschreibung

• Geltenden Rechtsrahmen für deine Stelle und den Beschaffungsgegenstand prüfen.
• Relevante Teile der EN 301 549 sowie die anzuwendende Fassung festlegen.
• Nutzungsszenarien einschließlich Dokumenten, Schnittstellen und mobilen Funktionen beschreiben.
• Mindestanforderungen in der Leistungsbeschreibung konkret und testbar formulieren.
• Eignungsanforderungen auf nachweisbare Erfahrung und fachlich geeignetes Personal begrenzen.
• Zuschlagskriterien mit transparenter Bewertungsmatrix ausgestalten.
• Nachweise, Testverfahren und Abnahmekriterien verbindlich festlegen.
• Mängelprozess für Releases, Updates und Erweiterungen vertraglich regeln.
• Verantwortlichkeiten für Inhalte, Konfigurationen und Drittkomponenten klar zuordnen.

Bei uns behandeln wir solche Fragen nicht nur aus technischer Sicht, sondern entlang des gesamten Vergabe- und Vertragsprozesses. Passende Seminare und Termine findest du bei uns auf cmt.de.