Vorlagen und Beispiele für das Ausschreibungs- und Vergabeverfahren von Desktop- und Web-Anwendungen
Version: 1.0
Sie können diese Handreichung als PDF-Datei (Öffnet PDF-Dokument) oder DOCX-Datei (Öffnet Word-Dokument) herunterladen.
0. Einleitung (4 min)
1. Abschnitt in den Vergabeunterlagen zum Ziel der barrierefreien Gestaltung (5 min)
2. Anforderungen an den Auftragnehmer und das eingesetzte Personal (15 min)
3. Anforderungen an den Leistungsgegenstand und den Leistungsprozess (32 min)
4. Gutachten und Prüfberichte (9 min)
5. Tabellarische Übersicht aller Formulierungsvorschläge (5 min)
6. Anhang: Linkliste (5 min)
7. Anhang: Lizenzinformationen für diese Handreichung (1 min)
Von einer modernen und zukunftsfähigen IT wird erwartet, dass sie barrierefrei zugänglich und nutzbar ist. Das Behindertengleichstellungsgesetz verpflichtet in § 12a Abs. 1 Satz 2 BGG dazu, elektronisch unterstützte Verwaltungsabläufe sowie die Verfahren zur elektronischen Vorgangsbearbeitung und zur elektronischen Aktenführung, einschließlich der elektronischen Dokumente und Formulare, barrierefrei zu gestalten. Inhaltsgleiche oder vergleichbare Verpflichtungen ergeben sich auch aus den Behindertengleichstellungsgesetzen der Bundesländer sowie aus zahlreichen Fachgesetzen (siehe dazu die Vertiefungshinweise im Anhang, unter 6.1). Nach § 12a Abs. 2 BGG erfolgt die barrierefreie Gestaltung nach Maßgabe der Barrierefreie-Informationstechnik-Verordnung (BITV 2.0) und, soweit diese keine Vorgaben enthält, nach den allgemein anerkannten Regeln der Technik. Auch zahlreiche andere Rechtsvorschriften verweisen zur barrierefreien Gestaltung auf die BITV 2.0.
Darüber hinaus verpflichtet das Gesetz gegen Wettbewerbsbeschränkungen in § 121 Abs. 2 GWB dazu, bei Ausschreibungs- und Vergabeverfahren die Anforderungen an die Barrierefreiheit in die Leistungsbeschreibung aufzunehmen. Diese Verpflichtung besteht auch dann, wenn die Behindertengleichstellungsgesetze von Bund und Ländern keine ausdrückliche Regelung zur Barrierefreiheit enthalten. Lässt sich – wie im Regelfall – bereits den Behindertengleichstellungsgesetzen von Bund und Ländern oder den einschlägigen Fachgesetzen eine Verpflichtung zur Barrierefreiheit entnehmen, dann darf das Ausschreibungs- und Vergabeverfahren nicht dahinter zurückbleiben.
Die Anforderungen an die Barrierefreiheit, die eine IT-Lösung in jedem Fall erfüllen muss, sind deshalb als Ausschlusskriterien in die Leistungsbeschreibung aufzunehmen.
In der Unterschwellenvergabeordnung haben sich der Bund und die Länder zudem darauf verständigt, die Regelungen zur Barrierefreiheit in § 121 Abs. 2 GWB und in § 58 Abs. 2 Nr. 1 der Vergabeverordnung auch auf Ausschreibungen unterhalb der EU-Schwellenwerte anzuwenden (§§ 23 Abs. 4, 43 Abs. 2 Nr. 1 UVGO).
Die vorliegende Handreichung zeigt für eine neu zu entwickelnde IT-Lösung (Desktop- und Web-Anwendung) auf, wie sich die Vorgaben zur Barrierefreiheit in einem Ausschreibungs- und Vergabeverfahren umsetzen lassen. Die Handreichung gilt nicht für Standardsoftware und solche, die an Kundenbedürfnisse angepasst wird. Hierzu enthält die Handreichung zahlreiche Vorlagen mit konkreten Anregungen und Beispielen, die sich in die Ausschreibungs- und Vergabeunterlagen übernehmen lassen. Den einzelnen Formulierungsvorschlägen ist jeweils eine kurze Erläuterung (Zielsetzung) dazu vorangestellt, aus der sich ergibt, warum der Textbaustein für das Ausschreibungs- und Vergabeverfahren wichtig ist. Ergänzt werden die Textbausteine durch Hinweise zu den bestehenden Anpassungsmöglichkeiten. Die Handreichung entbindet nicht von der Verpflichtung, bei jeder Ausschreibung selbständig zu prüfen, wie sich die Barrierefreiheit bestmöglich in den Ausschreibungs- und Vergabeunterlagen berücksichtigen lässt.
Schon aus diesem Grund kann keine Gewähr für die Richtigkeit und Vollständigkeit der wiedergegebenen Formulierungsvorschläge und Anregungen übernommen werden.
Barrierefreiheit kann nur gelingen, wenn die erforderlichen Weichenstellungen bereits im Ausschreibungs- und Vergabeverfahren vorgenommen werden. Hierfür bietet die Handreichung Unterstützung und Hilfestellung.
In die Ausschreibungs- und Vergabeunterlagen ist ein eigener Abschnitt zur Barrierefreiheit aufzunehmen, z. B. in der Leistungsbeschreibung. Der Abschnitt formuliert allgemeine Anforderungen an die Barrierefreiheit des Ausschreibungsgegenstandes, erläutert die Ziele einer barrierefreien Gestaltung und verdeutlicht, dass die Anforderungen zur Barrierefreiheit eine wesentliche Voraussetzung für die Qualität der ausgeschriebenen IT-Lösung bilden.
Die Barrierefreiheit der zu erstellenden IT-Lösung ist im Rahmen der Entwicklung und Programmierung von Beginn an konsequent, umfassend und uneingeschränkt zu verwirklichen. Die IT-Lösung muss auch für Menschen mit behinderungsbedingten Einschränkungen (Nutzung ohne oder mit eingeschränktem Sehvermögen, ohne oder mit eingeschränktem Hörvermögen, ohne oder mit eingeschränktem Sprachvermögen, mit eingeschränkter Reichweite, Handhabung oder Kraft, ohne Risiko epileptischer Anfälle, mit eingeschränkten kognitiven, sprachlichen oder Lernfähigkeiten; siehe EN 301 549, Abschnitt 4.2) barrierefrei zugänglich und nutzbar sein.
Hierzu sind die Anforderungen zur Barrierefreiheit, die sich aus den einschlägigen technischen Standards (insbesondere EN 301 549, DIN EN ISO 9241-171 und DIN ISO 14289-1) und aus der Handreichung „Barrierefreie Gestaltung von User Interface-Elementen“ https://handreichungen.bfit-bund.de/barrierefreie-uie/ ergeben, einzuhalten und umzusetzen.
Barrierefreiheit bedeutet in diesem Zusammenhang, dass eine IT-Lösung für alle Nutzenden in der allgemein üblichen Weise, ohne besondere Erschwernis und grundsätzlich ohne fremde Hilfe zugänglich und bedienbar ist (siehe § 4 BGG und die entsprechenden Vorschriften in den Behindertengleichstellungsgesetzen der Länder). Soweit die IT-Lösung nicht bereits selbst assistive Technologien enthält, muss über eine Schnittstelle für assistive Technologien eine uneingeschränkte Nutzung ermöglicht werden. Von Barrierefreiheit in diesem Sinn kann nicht gesprochen werden, wenn für assistive Technologien erst Anpassungen z. B. durch eine Hilfsmittelfirma programmiert werden müssten.
Dies bedeutet, dass unter anderem folgende Voraussetzungen erfüllt sein müssen:
Die vollständige Bedienbarkeit per Tastatur muss für die gesamte Anwendung gewährleistet sein.
Die Größe von Schrift und Symbolen, sowie Farben und Kontraste müssen individuell einstellbar sein.
Die Bedienbarkeit mit einem Screenmagnifier (Vergrößerungssoftware) wird durchgängig unterstützt (einschließlich Fokusverfolgung und Schriftglättung).
Die uneingeschränkte Nutzbarkeit und Bedienbarkeit mit einem Screenreader (einschließlich Braillezeile und Sprachausgabe) wird für die gesamte Anwendung gewährleistet.
Die gesamte Anwendung ist vollständig über eine Spracheingabesoftware bedienbar.
An den IT-Arbeitsplätzen des Auftraggebers werden – abhängig von den jeweiligen Anforderungen der betroffenen Nutzenden – derzeit insbesondere folgende Produkte assistiver Technologien zur Unterstützung motorisch eingeschränkter, sehbehinderter oder blinder Personen eingesetzt:
Screenreader [Produktnennung, siehe Anpassungsmöglichkeiten]
Screenmagnifier (Vergrößerungssoftware) [Produktnennung, siehe Anpassungsmöglichkeiten]
Sprachsteuerungssoftware [Produktnennung, siehe Anpassungsmöglichkeiten]
Die genannten Technologien werden für die Bewertung der Barrierefreiheit der IT-Lösung herangezogen. Aufgrund der unterschiedlichen Anforderungen der einzelnen Nutzenden muss davon ausgegangen werden, dass an den verschiedenen Arbeitsplätzen des Auftraggebers unterschiedliche Produkte für Vergrößerung und als Screenreader sowie zur Steuerung über Spracheingabe eingesetzt werden. Deshalb ist Robustheit im Sinne der EN 301 549, Abschnitt 9.4, 10.4 und 11.4, eine wichtige Voraussetzung.
Die zu entwickelnde IT-Lösung muss die Anforderungen an die Barrierefreiheit erfüllen, damit sie für den operativen Betrieb freigegeben werden kann. Die einzuhaltenden Anforderungen an die Barrierefreiheit ergeben sich aus den in der Leistungsbeschreibung referenzierten Normen und Standards. Die Handreichung „Barrierefreie Gestaltung von User Interface-Elementen" [https://handreichungen.bfit-bund.de/barrierefreie-uie/] ist als Ergänzung hierzu – ohne Anspruch auf Vollständigkeit – zu verstehen. Sie ersetzt nicht die Einhaltung der genannten Normen und Standards in der jeweils aktuellen Fassung.
Im Formulierungsvorschlag sind die an den Arbeitsplätzen der Beschäftigten eingesetzten assistiven Technologien unter Angabe der jeweiligen Produktbezeichnung zu nennen.
Für das Betriebssystem Windows gängige Screenreader sind bspw. JAWS und NVDA, gängige Vergrößerungsprogramme mit ergänzender Sprachausgabe bspw. ZoomText und SuperNova.
Für das Betriebssystem macOS und iOS sind gängige Screenreader bspw. VoiceOver und maginifier Zoom
Für das Betriebssystem Android ist der gängige Screenreader bspw. TalkBack
Als Programm zur Sprachsteuerung werden bspw. Dragon Naturally Speaking oder betriebssystem-eigene Funktionen eingesetzt.
für das Betriebssystem Linux gängige Screenreader bspw. Orca (Open Source) und SpeakUp (Open Source)
Zu jedem Hilfsmittel sollten mindestens zwei verschiedene Produkte in den Formulierungsvorschlag aufgenommen werden.
Anforderungen an die Eignung des Auftragnehmers und das eingesetzte Personal sollen sicherstellen, dass ein Bieter in einem Ausschreibungs- und Vergabeverfahren nur dann den Zuschlag erhält, wenn er über die erforderliche Qualifikation und Erfahrung verfügt. Zur Verwirklichung von Barrierefreiheit kommt es deshalb neben der Formulierung des Leistungsgegenstandes in erheblichem Umfang auch darauf an, ob die erforderliche Qualifikation und Erfahrung vorhanden sind. Anforderungen an die Eignung können sich auf das Unternehmen des Bieters beziehen oder auf das mit der Ausführung des konkreten Auftrags beauftragte Personal.
Anforderungen an die Eignung des Bieters (Eignungskriterien) sind in der Regel als Ausschlusskriterien (A-Kriterien) zu formulieren. Sie werden bereits in der Eignungsprüfung berücksichtigt (§ 122 Abs. 2 GWB, § 46 Abs. 1 VgV). Ein Bieter, der die Eignungskriterien nicht erfüllt, kann an dem Ausschreibungs- und Vergabeverfahren nicht teilnehmen.
Andere Anforderungen an die Eignung, z. B. zur Qualifikation und Erfahrung des eingesetzten Personals, können im Rahmen der Zuschlagserteilung auch als Bewertungskriterien (B-Kriterien) berücksichtigt werden (vgl. § 122 GWB, § 58 Abs. 2 Satz 1 Nr. 2 VgV). Sie sind in die Leistungsbeschreibung aufzunehmen.
Der Nachweis der Eignung kann beispielsweise durch die Vorlage von Referenzen erbracht werden (vgl. § 46 Abs. 1 Nr. 3 und § 48 VgV).
Anforderungen an die Eignung des Bieters sollen sicherstellen, dass der Bieter in seinem Unternehmen über die erforderlichen Kenntnisse und Erfahrungen zur Verwirklichung von Barrierefreiheit verfügt. Hierzu gehören neben dem erforderlichen Know-how und ausreichenden Kenntnissen auch ein Bestand an qualifizierten Mitarbeitern sowie regelmäßige Schulungs- und Qualifizierungsmaßnahmen. Nur diejenigen Bieter, die die als A-Kriterien formulierten Eignungskriterien erfüllen, kommen für eine Zuschlagserteilung in Betracht.
Der Auftraggeber kann in den Ausschreibungs- und Vergabeunterlagen festlegen, dass der Nachweis der Eignung durch die Nennung von Referenzen zu erbringen ist. Hierbei ist wichtig, dass die Ausschreibungsunterlagen genaue Inhaltsvorgaben zu den zu erbringenden Referenzen enthalten. Die Formulierung als A-Kriterium stellt sicher, dass nur Unternehmen mit den entsprechenden Erfahrungen im weiteren Auswahlverfahren berücksichtigt werden.
Benennen Sie drei Referenzobjekte zur Entwicklung einer IT-Lösung (Desktop-Anwendung oder Web-Anwendung), die Sie in den letzten drei Jahren erfolgreich abgeschlossen und in deren Rahmen Sie die Barrierefreiheit verwirklicht haben. Die Realisierung eines Webauftritts (Internet bzw. Intranet) reicht hierfür nicht aus. In den zu benennenden Referenzobjekten muss Ihr Anteil in den Bereichen Design und Realisierung der Benutzerschnittstellen oder Prüfung und Test auf Barrierefreiheit bei mindestens 70 Prozent liegen.
Die Referenzen sind dem Angebot zusammen mit insbesondere folgenden Angaben beizufügen:
Auftraggeber mit Adresse sowie eine Ansprechperson mit Telefonnummer und E-Mail-Adresse
Kurze Beschreibung der Fachlichkeit der IT-Lösung
Kurze Darstellung der von Ihnen umgesetzten Maßnahmen zur Barrierefreiheit
Abhängig von dem eigenen Ausschreibungsgegenstand sind Art und Umfang der Referenzobjekte, für die Referenzen vorzulegen sind, und die erforderlichen Angaben zur Barrierefreiheit zu ergänzen und zu präzisieren. Möglich sind auch Angaben zu den Personentagen und der Qualifikation des eingesetzten Personals, die in den Referenzobjekten erfüllt sein müssen.
Der Textbaustein sollte dahingehend präzisiert werden, in welcher Technologie die Entwicklung erfolgen soll, damit der Bieter genau in diesem Bereich Expertise nachweisen muss.
Bei einem vorgelagerten Teilnehmerwettbewerb (z. B. für ein Verhandlungsverfahren oder einen wettbewerblichen Dialog) kann die Vorlage von Referenzen statt als Ausschlusskriterium auch im Rahmen eines Bewertungskriteriums berücksichtigt werden.
In diesem Fall ist es erforderlich, den Ausschreibungs- und Vergabeunterlagen eine Bewertungsmatrix beizufügen und eine Gewichtung der Bewertungskriterien vorzunehmen.
Stellen Sie anhand von drei Referenzobjekten Ihre Erfahrungen zur Verwirklichung von Barrierefreiheit bei der Planung und Entwicklung von IT-Lösungen (Desktop-Anwendung oder webbasierte Anwendung) dar, die Sie in den letzten drei Jahren erfolgreich abgeschlossen und in deren Rahmen Sie die Barrierefreiheit verwirklicht haben.
Ihr Angebot, dem die Referenzen beizufügen sind, muss insbesondere folgende Angaben enthalten:
Auftraggeber mit Adresse sowie eine Ansprechperson mit Telefonnummer und E-Mail-Adresse
Kurze Beschreibung der Fachlichkeit der IT-Lösung
Umfang des Projekts in Personentagen und Zeitdauer
Anteil, den Sie in den Bereichen Design und Realisierung der Benutzerschnittstellen sowie Prüfung und Test auf Barrierefreiheit übernommen haben
Kurze Darstellung der von Ihnen umgesetzten Maßnahmen und Tätigkeiten zur Barrierefreiheit
Darstellung, welche Anforderungen zur Barrierefreiheit erfüllt, teilweise erfüllt oder nicht erfüllt wurden
Es können maximal drei Referenzobjekte eingereicht werden. Jedes Referenzobjekt wird einzeln bewertet. Pro Referenzobjekt sind maximal drei Punkte möglich.
0 Punkte:
Ein Referenzobjekt, zu dem die Angaben nicht vollständig sind, wird mit 0 Punkten bewertet.
Stufe 1: 1 Punkt pro eingereichtem Objekt möglich
Der Anteil des Bieters an der Entwicklung in den Bereichen Design und Realisierung der Benutzungsschnittstellen oder Prüfung und Test der Barrierefreiheit lag bei mindestens 50 Prozent. Die Anforderungen zur Barrierefreiheit wurden im Wesentlichen umgesetzt. Die Angaben zum Referenzobjekt sind vollständig.
Stufe 2: 2 Punkte pro eingereichtem Objekt möglich
Der Anteil des Bieters an der Entwicklung in den Bereichen Design und Realisierung der Benutzerschnittstellen oder Prüfung und Test der Barrierefreiheit lag bei mindestens 80 Prozent. Die Anforderungen zur Barrierefreiheit wurden im Wesentlichen umgesetzt. Die Angaben zum Referenzobjekt sind vollständig.
Stufe 3: 3 Punkte pro eingereichtem Objekt möglich
Der Anteil des Bieters an der Entwicklung in den Bereichen Design und Realisierung der Benutzerschnittstellen sowie Prüfung und Test der Barrierefreiheit lag jeweils bei mindestens 80 Prozent. Die Anforderungen zur Barrierefreiheit wurden nahezu ausnahmslos umgesetzt. Die Angaben zum Referenzobjekt sind vollständig.
Die Anforderungen an die Referenzobjekte sind abhängig von dem eigenen Ausschreibungsgegenstand anzupassen oder zu ergänzen.
Die Verwirklichung der Barrierefreiheit einer IT-Lösung setzt voraus, dass die Leistungsprozesse des zukünftigen Auftragnehmers entsprechend gestaltet sind. Bei der Ausschreibung sollte daher auch bewertet werden, inwieweit bei der Entwicklung von IT-Lösungen die Barrierefreiheit in der Unternehmensstrategie verankert ist. Für diese Bewertung ist ein eigenständiges Bewertungskriterium erforderlich.
Stellen Sie dar, wie die Qualitätsanforderung „Barrierefreiheit“ in Ihrem Unternehmen im Bereich der Software-Entwicklung umgesetzt wird. Gehen Sie insbesondere darauf ein,
wie Ihre Mitarbeitenden zur digitalen Barrierefreiheit ausgebildet sind und geschult werden (aufgeteilt nach den Projektrollen Projektleitung, Oberflächen-Design, Software-Entwicklung und Software-Test),
ob digitale Barrierefreiheit in der Strategie Ihres Unternehmens im Bereich der Software-Entwicklung verankert ist, z. B. über einzuhaltende Design-Grundsätze oder Entwicklungs-Richtlinien oder entwicklungsbegleitende Barrierefreiheitsprüfungen und
inwieweit ein kontinuierlicher Verbesserungsprozess zur digitalen Barrierefreiheit in Ihrem Unternehmen im Bereich der Software-Entwicklung etabliert ist.
0 - 2 Punkte (schlecht):
Das Thema Barrierefreiheit ist nicht durchgängig in der Entwicklung von IT-Lösungen mit konkreten Aktivitäten verankert. ODER: Es findet keine entwicklungsbegleitende Prüfung der Barrierefreiheit von IT-Lösungen statt. ODER: Es werden keine Kompetenzen hinsichtlich barrierefreier Gestaltung in die Entwicklung von IT-Lösungen eingebracht.
3 - 6 Punkte (mittel):
Das Thema Barrierefreiheit ist durchgängig im Entwicklungsprozess von IT-Lösungen verankert, es finden entwicklungsbegleitende Prüfungen statt und Kompetenzen werden eingebracht. Bei Nutzungs- und Usability-Tests von IT-Lösungen werden die Anforderungen von Nutzenden mit Beeinträchtigungen nicht systematisch berücksichtigt. Das Thema Barrierefreiheit ist nicht in der Strategie des Unternehmens verankert und auch nicht Gegenstand eines kontinuierlichen Verbesserungsprozesses.
7 - 10 Punkte (gut):
Barrierefreiheit ist in der Strategie und im kontinuierlichen Verbesserungsprozess des Unternehmens verankert, wird bei der Entwicklung von IT-Lösungen kontinuierlich berücksichtigt, Anforderungen von Nutzenden mit Beeinträchtigungen werden in Tests berücksichtigt, Expertenwissen ist vorhanden.
Das Bewertungsschema ist in den Ausschreibungsunterlagen zu veröffentlichen. Das Kriterium ist entsprechend der Bedeutung der Barrierefreiheit für die zu beschaffende IT-Lösung zu gewichten.
Der Formulierungsvorschlag kann angepasst werden, indem noch einmal explizit auf das in den Ausschreibungsunterlagen geforderte Expertenwissen eingegangen wird (vgl. Kapitel 2.2.1, 2.2.2 und 2.2.3).
Die Bewertungsmatrix kann auch in der Weise formuliert werden, dass für die einzelnen Aspekte jeweils gesondert Punkte vergeben werden (vgl. Bewertungsvorschlag aus 2.1.2).
Bei der Planung und Entwicklung einer neuen IT-Lösung, z. B. einer Fachanwendung für einen öffentlichen Auftraggeber, kann die Qualität des eingesetzten Personals erheblichen Einfluss auf das Niveau der Auftragsausführung haben. Bei der Formulierung der Ausschreibungs- und Vergabeunterlagen ist deshalb sicherzustellen, dass das vom Auftragnehmer für die Ausführung des konkreten Auftrags eingesetzte Personal über die erforderlichen Qualifikationen und Erfahrungen hinsichtlich der geforderten Barrierefreiheit verfügt. Hierzu kann dem Auftragnehmer im Ausschreibungs- und Vergabeverfahren auch aufgegeben werden, zur Ausführung des Auftrags einen oder mehrere Spezialisten zur Barrierefreiheit und Usability zu stellen, deren Kenntnisse und Erfahrungen durch geeignete Nachweise zu belegen sind.
Um die Verwirklichung der Barrierefreiheit bei der Planung und Entwicklung der IT-Lösung von dem Oberflächen-Design über die verwendeten UI-Elemente bis zur Interoperabilität mit assistiven Technologien sicherzustellen, sollte dem Auftragnehmer aufgegeben werden, auf Seiten der Entwickler einen Software-Experten für Barrierefreiheit zu stellen (erstes Ausschlusskriterium), der über die erforderlichen Kenntnisse und Erfahrungen verfügt (zweites Ausschlusskriterium).
Der Auftragnehmer ist verpflichtet, für die Planung und Entwicklung der IT-Lösung einen Software-Experten für Barrierefreiheit (Expert oder Senior Expert) zu stellen [Erstes Ausschlusskriterium]. Der Software-Experte ist verantwortlich für die korrekte Umsetzung der Anforderungen zur Barrierefreiheit. Zu seinen Aufgaben gehören insbesondere:
Mitwirkung bei der Planung und Entwicklung der IT-Lösung (Styleguide, Design-Entwürfe, Tastatur-Konzept, …),
die Erstellung von Vorgaben und Regeln für die Software-Entwickler zur Umsetzung von Anforderungen an die Barrierefreiheit,
die Erstellung von Vorgaben an die Verwendung barrierefreier UI-Elemente und die Unterstützung der Softwareentwickler zu Fragen der Barrierefreiheit.
Der Software-Experte für Barrierefreiheit muss mindestens über die folgenden Kenntnisse und Erfahrungen verfügen [Zweites Ausschlusskriterium]:
Entwicklung von Client / Server-Anwendungen, bei der anteilig eine fest installierte Softwareapplikation auf dem Client läuft (Desktop-Anwendung) und die Entwicklung von reinen Web-Anwendungen nach dem Client / Server-Modell, bei der auf dem Client (außer einem Browser) keine Software festinstalliert wird, jeweils im Hinblick auf die Realisierung der Bedienbarkeit der IT-Lösung
per Tastatur und Shortcuts,
mit einem Screenmagnifier (Bildschirmlupe mit ergänzender Sprachausgabe),
mit einem Screenreader (einschließlich Braillezeile und Sprachausgabe) sowie
mittels einer Sprachsteuerungssoftware.
Beratung und Unterstützung im Rahmen der Entwicklung von IT-Lösungen zur Umsetzung der Anforderungen zur Barrierefreiheit und
Durchführung von entwicklungsbegleitenden Prüfungen und Tests zur Barrierefreiheit.
Dem Auftragnehmer ist zudem aufzugeben, zusammen mit dem Angebot Nachweise zu den Kenntnissen und Erfahrungen des Software-Experten für Barrierefreiheit vorzulegen. Das Erstellen und Gestalten von Websites (Internet und Intranet) reicht als Nachweis für die Kenntnisse und Erfahrungen nicht aus. Soweit den Bietern die Möglichkeit gegeben wird, die Nachweise durch Vorlage von Referenzen zu erbringen, sollte die Zahl der vorzulegenden Referenzen auf maximal drei Referenzen, die nicht älter als fünf Jahre sind, festgelegt werden.
Für die zu fordernden Kenntnisse und Erfahrungen des Software-Experten für Barrierefreiheit (zweites Ausschlusskriterium) bestehen folgende Anpassungsmöglichkeiten.
Die von dem Software-Experten für Barrierefreiheit zu fordernden Kenntnisse und Erfahrungen müssen zumindest die für die ausgeschriebene IT-Lösung vorgesehene Architektur (Desktop-Anwendung oder Web-Anwendung) und die jeweilige Entwicklungsumgebung abdecken. Wenn der Software-Experte für Barrierefreiheit mit beiden Bereichen vertraut ist, ist eine höhere Qualifikation gegeben.
Die zu fordernden Kenntnisse und Erfahrungen des Software-Experten für Barrierefreiheit können stattdessen auch als Bewertungskriterium festgelegt werden (§ 58 Abs. 2 Satz 1 Nr. 2 VgV). In diesem Fall ist zusätzlich eine Bewertungsmatrix erforderlich.
Die Verwirklichung von Barrierefreiheit kann nur gelingen, wenn die Umsetzung der Barrierefreiheit von der Planung und Entwicklung bis zur Fertigstellung von Beginn an geprüft und als Teil der Qualitätssicherung regelmäßig kontrolliert wird. Hierzu sollte dem Auftragnehmer aufgegeben werden, einen Test-Experten für Barrierefreiheit zu stellen (erstes Ausschlusskriterium), der über die erforderlichen Kenntnisse und Erfahrungen verfügt (zweites Ausschlusskriterium).
Der Auftragnehmer ist verpflichtet, für die Planung und Entwicklung der IT-Lösung einen Test-Experten für Barrierefreiheit (Expert oder Senior Expert) zu stellen [Erstes Ausschlusskriterium]. Der Test-Experte für Barrierefreiheit muss mindestens über die folgenden Kenntnisse und Erfahrungen verfügen [Zweites Ausschlusskriterium]:
Fundierte Kenntnisse und mehrjährige Erfahrungen als Test-Experte für Barrierefreiheit bei der Begutachtung und dem Testen von Desktop-Anwendungen (Software) und Web-Anwendungen (IT-Fachanwendungen) auf Barrierefreiheit
Fundierte Kenntnisse und praktische Erfahrungen bei der Prüfung von User-Interface-Elementen auf Barrierefreiheit (insbesondere zu Abschnitt 11.5 der EN 301 549 und zu Abschnitt 8 der DIN ISO 14289-1)
Vertiefte Kenntnisse und praktische Erfahrungen in der Nutzung von assistiven Technologien wie Screenreader (einschließlich Braillezeile und Sprachausgabe), Screenmagnifier (Bildschirmlupe mit ergänzender Sprachausgabe) und Programmen zur Steuerung über eine Spracheingabe
Mehrjährige Mitarbeit bei der Planung und Entwicklung von IT-Lösungen als Test-Experte und Berater für Barrierefreiheit
Dem Auftragnehmer ist zudem aufzugeben, zusammen mit dem Angebot Nachweise zu den Kenntnissen und Erfahrungen des Test-Experten für Barrierefreiheit vorzulegen. Das Prüfen von Websites (Internet und Intranet) auf Barrierefreiheit reicht als Nachweis für die Kenntnisse und Erfahrungen nicht aus.
Die zu fordernden Kenntnisse und Erfahrungen des Test-Experten für Barrierefreiheit (zweites Ausschlusskriterium) können stattdessen auch als Bewertungskriterium festgelegt werden (§ 58 Abs. 2 Satz 1 Nr. 2 VgV). In diesem Fall ist zusätzlich eine Bewertungsmatrix erforderlich.
Es gibt einen großen Überschneidungsbereich zwischen Barrierefreiheit und Usability. Zahlreiche Anforderungen an die Usability sind auch für die Verwirklichung von Barrierefreiheit erforderlich. Der für die Entwicklung der ausgeschriebenen IT-Lösung zuständige Auftragnehmer sollte daher auch einen Experten zur Usability stellen (erstes Ausschlusskriterium), der über die erforderlichen Kenntnisse und Erfahrungen verfügt (zweites Ausschlusskriterium), so dass die Anforderungen aller Nutzergruppen an die Usability, einschließlich der Anforderungen von Menschen mit unterschiedlichen Beeinträchtigungen, bei der Planung und Entwicklung der IT-Lösung berücksichtigt werden.
Der Auftragnehmer ist verpflichtet, für die Planung und Entwicklung der IT-Lösung einen Experten für Usability (Expert oder Senior Expert) zu stellen (Ausschlusskriterium). Der Experte für Usability ist verantwortlich für die Gebrauchstauglichkeit und Nutzerfreundlichkeit der IT-Lösung. Zu seinen Aufgaben gehören insbesondere:
Mitwirkung bei der Planung und Entwicklung der IT-Lösung (Styleguide, Design-Entwürfe, Tastatur-Konzept, …)
Durchführung von Experten-Reviews zur Gebrauchstauglichkeit (DIN EN ISO 9241-110, DIN EN ISO 9241-112 und DIN EN ISO 9241-125)
Durchführung von Usability-Tests mit potenziellen Nutzergruppen (DIN EN ISO 9241-210) unter Einbeziehung von Menschen mit unterschiedlichen Beeinträchtigungen
Der Experte für Usability muss mindestens über die folgenden Kenntnisse und Erfahrungen verfügen (Ausschlusskriterium):
mehrjährige Erfahrung als Usability-Experte
Mitarbeit bei der Planung und Konzeption von IT-Lösungen
Usability-Tests und Experten-Reviews
Dem Auftragnehmer ist zudem aufzugeben, zusammen mit dem Angebot Nachweise zu den Kenntnissen und Erfahrungen des Usability-Experten vorzulegen.
Die zu fordernden Kenntnisse und Erfahrungen des Usability-Experten (zweites Ausschlusskriterium) können stattdessen auch als Bewertungskriterium festgelegt werden (§ 58 Abs. 2 Satz 1 Nr. 2 VgV). In diesem Fall ist zusätzlich eine Bewertungsmatrix erforderlich.
Die Leistungsbeschreibung gehört zum Kernbereich der Ausschreibungs- und Vergabeunterlagen, da hier die Anforderungen an den Leistungsgegenstand festgelegt werden. Anforderungen an die Barrierefreiheit, die eine IT-Lösung aufgrund der gesetzlichen Vorgaben oder aufgrund von zusätzlichen Vorgaben des Auftraggebers in jedem Fall erfüllen muss, müssen in der Leistungsbeschreibung klar und eindeutig benannt werden. Sie sind als Ausschlusskriterien (A-Kriterien) zu formulieren, da nur so ihre Einhaltung rechtlich verbindlich festgelegt wird. Um die Verwirklichung von Barrierefreiheit sicherzustellen, sollte die Leistungsbeschreibung hierzu nicht nur Anforderungen an den Leistungsgegenstand (die ausgeschriebene IT-Lösung) enthalten. Zu formulieren sind auch Anforderungen an den Entwicklungsprozess und die Dokumentation.
Zusätzlich zu A-Kriterien können weitere Gesichtspunkte zur Barrierefreiheit, die darüber hinausgehen, in der Leistungsbeschreibung im Rahmen von Bewertungskriterien (B-Kriterien) berücksichtigt werden (§ 127 Abs. 1 Satz 4 GWB, § 58 Abs. 2 Nr. 1 VgV). Ein Bieter, der bei den Bewertungskriterien gut abschneidet, kann hierdurch seine Chancen auf den Zuschlag erhöhen. Die zusätzliche Berücksichtigung der Barrierefreiheit in der Leistungsbeschreibung im Rahmen von B-Kriterien ist daher ein wichtiges Instrument, um auch hinsichtlich der Barrierefreiheit einen Wettbewerb um die beste Lösung zu erreichen. Bewertungskriterien zur Barrierefreiheit können sich sowohl auf zusätzliche Anforderungen an den Ausschreibungsgegenstand als auch auf den Entwicklungsprozess beziehen.
In der Leistungsbeschreibung sind die zur Herstellung von Barrierefreiheit zu beachtenden Anforderungen vollständig und ausführlich zu beschreiben (vgl. § 121 Abs. 1 GWB: „so eindeutig und erschöpfend wie möglich“). Dies kann in Form von Leistungs- oder Funktionsanforderungen, durch Bezugnahme auf technische Spezifikationen oder als Kombination davon erfolgen. Hierzu kann auf die in internationalen Standards aufgeführten Anforderungen zur Barrierefreiheit Bezug genommen werden. Aus der Leistungsbeschreibung muss klar und eindeutig hervorgehen, welche der in Bezug genommenen Anforderungen zur Barrierefreiheit von dem Auftragnehmer einzuhalten sind. Darüber hinaus können in der Leistungsbeschreibung weitere Anforderungen zur Barrierefreiheit festgelegt werden, die von dem Auftragnehmer ebenfalls einzuhalten sind.
Der europäische Standard EN 301 549 formuliert Anforderungen an die Barrierefreiheit von Hardware (Abschnitt 8), Websites (Abschnitt 9), elektronischen Dokumenten (Abschnitt 10) und Software (Abschnitt 11), die durch Anforderungen in den übrigen Abschnitten des Standards ergänzt werden. In seinem Annex A listet er in Tabelle A.1 für Websites (Internet, Intranet und Extranet) und in Tabelle A.2 für mobile Anwendungen (Software) die Anforderungen zur Barrierefreiheit auf, die nach den Vorgaben der EU mindestens einzuhalten sind. Weitere Anforderungen für Websites ergeben sich aus den Web Content Accessibility Guidelines (WCAG), den Authoring Tool Accessibility Guidelines (ATAG) und den WAI Accessible Rich Internet Applications (WAI-ARIA). Zur barrierefreien Gestaltung zu beachten sind außerdem die in den DIN EN ISO 9241-171 formulierten „Leitlinien für die Zugänglichkeit von Software“ und der PDF/UA-Standard DIN ISO 14289-1.
Abhängig von der Art des Auftragsgegenstandes ergeben sich daraus unterschiedliche Anforderungen an die Formulierung der Leistungsbeschreibung. Content-Management-Systeme (CMS) und Autorenwerkzeuge für Webinhalte müssen die Einhaltung der Kriterien der WCAG ermöglichen und unterstützen. Hier sind daher neben den Anforderungen aus der EN 301 549 auch die WCAG und die ATAG zu beachten. Für Software, die dazu bestimmt und geeignet ist, den Inhalt von PDF-Dokumenten wiederzugeben, ist sicherzustellen, dass neben den Anforderungen aus der EN 301 549 auch die Anforderungen aus Abschnitt 8 der DIN ISO 14289-1 (PDF/UA-Standard) eingehalten werden, da Screenreader ansonsten nicht auf den Inhalt der Dokumente zugreifen können. Bei Verfahren zur elektronischen Vorgangsbearbeitung mit einer Textverarbeitung ist dafür zu sorgen, dass auch die zu erstellenden elektronischen Dokumente barrierefrei umgesetzt werden (EN 301 549, Abschnitt 10 und Abschnitt 11.8). Bei Verfahren zum ersetzenden Scannen ist darauf zu achten, dass automatisiert eine Texterkennung (OCR) erfolgt und dabei auch die zur Barrierefreiheit erforderlichen Strukturinformationen (vgl. DIN ISO 14289-1, Abschnitt 7) durch eine Layout-Erkennung mitgeliefert werden. Außerdem müssen in allen Fällen auch die Hilfe-Funktionen und Benutzerhandbücher barrierefrei zugänglich und nutzbar sein (EN 301 549, Abschnitt 12, und DIN EN ISO 9241-171, Abschnitt 11).
Für die Erstellung der Ausschreibungs- und Vergabeunterlagen ist daher stets sorgfältig zu prüfen, welche Anforderungen zur Verwirklichung von Barrierefreiheit des jeweiligen Ausschreibungsgegenstandes in die Leistungsbeschreibung aufzunehmen sind.
Die Auflistung der einzuhaltenden Anforderungen an die Barrierefreiheit ist bezogen auf den jeweiligen Ausschreibungsgegenstand zu ergänzen oder anzupassen. Nicht ausreichend ist es, zur Festlegung der Anforderungen an die Barrierefreiheit in der Leistungsbeschreibung lediglich auf § 3 der BITV 2.0 zu verweisen, da dieser Verweis nicht hinreichend bestimmt ist. Falsch wäre es, zur Festlegung der einzuhaltenden Anforderungen an die Barrierefreiheit in der Leistungsbeschreibung (ausschließlich) die WCAG zu nennen, da wesentliche Anforderungen an die Barrierefreiheit von IT-Lösungen beispielsweise zur Interoperabilität mit assistiven Technologien (siehe EN 301 549, Abschnitt 11.5 und DIN EN ISO 9241-171, Abschnitt 8.5) in den WCAG fehlen.
Durch die WCAG 2.2 vom Oktober 2023 wurden die WCAG um weitere Erfolgskriterien mit den Konformitätsstufen A und AA ergänzt, die in dem europäischen Standard EN 301 549 bisher noch fehlen (https://www.w3.org/TR/WCAG22/#new-features-in-wcag-2-2 ). Sinnvoll ist es, auch diese Anforderungen schon jetzt in die Leistungsbeschreibung aufzunehmen.
Weitere Anforderungen an die Barrierefreiheit, die in die Leistungsbeschreibung aufzunehmen sind, können sich daraus ergeben, dass Anforderungen der potenziellen Nutzergruppen durch die einzuhaltenden technischen Standards bisher nicht oder nur unzureichend berücksichtigt werden. Zu den potenziellen Nutzergruppen und deren funktionellen Einschränkungen, für die Barrierefreiheit herzustellen ist, listet die EN 301 549 insbesondere die folgenden Nutzungsarten auf:
Nutzung ohne Sehvermögen
Nutzung mit eingeschränktem Sehvermögen
Nutzung ohne Farbwahrnehmung
Nutzung ohne Hörvermögen
Nutzung mit eingeschränktem Hörvermögen
Nutzung ohne oder mit eingeschränktem Sprachvermögen
Nutzung mit eingeschränkter Handhabung oder Kraft
Nutzung mit eingeschränkter Reichweite
Nutzung ohne Risiko epileptischer Anfälle bei Photosensitivität
Nutzung mit eingeschränkten kognitiven Fähigkeiten
Vor der Erstellung der Leistungsbeschreibung ist daher zu prüfen, ob sich hieraus weitere Anforderungen an die Barrierefreiheit ergeben, die in die Leistungsbeschreibung aufzunehmen sind (§ 3 Abs. 3 BITV 2.0).
Der folgende Formulierungsvorschlag ist ein Beispiel für eine Anforderung, die sich auf Menschen mit Farbfehlsichtigkeit bezieht.
Je nach Art der ausgeschriebenen IT-Lösung und dem Kreis der möglichen Nutzer kann es geboten sein, weitere Nutzeranforderungen in die Leistungsbeschreibung aufzunehmen. Außerdem kann es sinnvoll sein, die Leistungsbeschreibung um folgende Formulierung zu ergänzen: „Soweit Teile der ausgeschriebenen IT-Lösung oder Nutzeranforderungen durch die in der Leistungsbeschreibung aufgeführten Anforderungen zur Barrierefreiheit nicht abgedeckt sind, ist die Barrierefreiheit nach dem Stand der Technik zu verwirklichen.“
Für zentrale Navigations- und Einstiegsangebote sowie Angebote, die eine Nutzerinteraktion ermöglichen, besteht nach § 3 Abs. 4 BITV 2.0 die Verpflichtung, in der Regel ein höheres Maß an Barrierefreiheit anzustreben. Zu den Angeboten, die eine beidseitige Nutzerinteraktion ermöglichen, gehören insbesondere das Ausfüllen von Formularen sowie die Durchführung von Authentifizierungs-, Identifizierungs- und Zahlungsprozessen (§ 3 Abs. 4 BITV 2.0). Den öffentlichen Auftraggeber trifft insoweit die Pflicht, vor einer Ausschreibung zu prüfen, wie sich die Barrierefreiheit über die Einhaltung der rechtlich verbindlichen Standards hinaus für den Ausschreibungsgegenstand verbessern lässt. Hierzu kann es zum einen geboten sein, weitere Anforderungen an die Barrierefreiheit, die in dem europäischen Standard EN 301 549 bisher nicht verbindlich aufgelistet werden, wie beispielsweise die Erfolgskriterien der WCAG mit der Konformitätsstufe AAA, ebenfalls in die Leistungsbeschreibung aufzunehmen. Zum anderen kann es geboten sein, in die Leistungsbeschreibung Anforderungen zur Usability und Nutzerfreundlichkeit aufzunehmen, die sicherstellen sollen, dass sich die ausgeschriebene IT-Lösung beispielsweise auch von blinden Nutzenden mit einem Screenreader (mit Braillezeile und Sprachausgabe) effizient und effektiv nutzen lässt.
Es folgen drei Formulierungsvorschläge, die beide eingefügt werden können.
Da die IT-Lösung (außer mit der Maus) auch vollständig mit Tastaturbefehlen bedienbar sein muss, ist der Auftragnehmer verpflichtet, für die IT-Lösung ein Tastaturkonzept zu erstellen und umzusetzen, das die folgenden Voraussetzungen erfüllt:
Alle Bedienelemente und Schaltflächen lassen sich grundsätzlich über die Tabulator-Taste oder die Pfeil-Tasten erreichen.
Es gibt eine Bereichsnavigation (z. B. zum Menüband und zurück), die einen schnellen Wechsel zwischen verschiedenen Bereichen der IT-Lösung ermöglicht.
Für die Schnell-Navigation sind Short-Cuts vorhanden.
Tastaturkonflikte mit assistiven Technologien werden vermieden.
In den Benutzereinstellungen können die Tastaturbelegungen für Short-Cuts geändert werden.
Die Tastaturbefehle werden in der Hilfe-Funktion und den Benutzerhandbüchern vollständig dokumentiert.
Das Tastaturkonzept muss eine effektive und effiziente Bedienung der IT-Lösung ermöglichen. Die Tastaturkonventionen des Betriebssystems oder der Plattform werden, soweit möglich, übernommen und dürfen nicht überschrieben werden. Bedienfunktionen, die mit der Maus möglich sind, müssen auch mit der Tastatur möglich sein.
Der Formulierungsvorschlag zur Tastaturbedienbarkeit ist nur ein Beispiel – neben weiteren Maßnahmen – für die Verwirklichung größtmöglicher Barrierefreiheit. Der Formulierungsvorschlag ist je nach Auftragsgegenstand anzupassen oder zu ergänzen.
Um ein höchstmögliches Maß (§ 3 Abs. 4 BITV 2.0) an Barrierefreiheit zu ermöglichen, müssen folgende Anforderungen umgesetzt werden:
[Liste der zusätzlich umzusetzenden Anforderungen an Barrierefreiheit hier einfügen, vgl. Anpassungsmöglichkeiten]
Durch den Auftraggeber ist zu prüfen, ob und welche Bestandteile der geplanten IT-Lösung ein höheres Maß an Barrierefreiheit erfüllen sollen. Ein höheres Maß an Barrierefreiheit lässt sich z. B. dadurch erreichen, dass zusätzlich zu den gesetzlichen Verpflichtungen weitere Anforderungen zur Barrierefreiheit in die Leistungsbeschreibung aufgenommen werden, die sich aus internationalen Standards und Richtlinien ergeben oder durch den Auftraggeber formuliert werden. Hierzu gehören beispielsweise die Erfolgskriterien der WCAG mit der Konformitätsstufe AAA, die in den EN 301 549 in Abschnitt 9.5 lediglich als fakultativ aufgelistet werden. Aus der Begründung zur BITV 2.0 ergibt sich, dass diese Anforderungen in der Regel für Nutzerinteraktionen ebenfalls eingehalten werden sollen (Bundesanzeiger 29.05.2019 B1, Seite 5). Da die IT an den Arbeitsplätzen der Beschäftigten stets eine Nutzerinteraktion ermöglicht, ist in der Leistungsbeschreibung auch festzulegen, ob und welche Erfolgskriterien der WCAG mit der Konformitätsstufe AAA von dem Auftragnehmer ebenfalls einzuhalten sind.
Auch aus anderen Standards und Richtlinien (z. B. DIN EN ISO 9241-110, DIN EN ISO 9241-112, DIN EN ISO 9241-125) können sich weitere Anforderungen ergeben, deren Übernahme zur Verbesserung der Barrierefreiheit dienlich sind.
Die Erfolgskriterien der WCAG mit der Konformitätsstufe AAA werden in dem europäischen Standard EN 301 549 in Abschnitt 9.5 als fakultativ aufgelistet. Sie gehen über den Standard EN 301 549 hinaus und ermöglichen es, ein höheres Maß an Barrierefreiheit zu verwirklichen. Stellen Sie dar, welche der nachfolgend aufgelisteten Anforderungen zur Barrierefreiheit von Ihnen bei einer Zuschlagserteilung in der ausgeschriebenen IT-Lösung ebenfalls umgesetzt werden und für welche Bereiche der IT-Lösung dies der Fall sein wird.
[Auflistung der Anforderungen]
Nehmen Sie in das Bewertungskriterium auf, für welche der in der EN 301 549 genannten Erfolgskriterien der WCAG mit der Konformitätsstufe AAA ein Bieter Punkte erhalten soll, wenn er deren Verwirklichung in der IT-Lösung zusagt.
Für jedes der angegebenen Kriterien gibt es bei Erfüllung einen Punkt, wenn dieses Kriterium bei allen Angeboten, die eine Nutzerinteraktion ermöglichen, wie beispielsweise das Ausfüllen von Formularfeldern oder die Durchführung von Authentifizierungs-, Identifizierungs- oder Zahlungsprozessen, durchgängig eingehalten wird. Zwei Punkte gibt es, wenn dieses Erfolgskriterium in der gesamten IT-Lösung durchgängig eingehalten wird.
Die Berücksichtigung von Anforderungen zur Barrierefreiheit im Rahmen von Bewertungskriterien bietet sich an für alle Anforderungen, die nicht schon als A-Kriterien in der Leistungsbeschreibung enthalten sind. Hierdurch kann den Bietern aufgegeben werden, in ihrem Angebot eigene Vorschläge zu machen, wie die Barrierefreiheit der ausgeschriebenen IT-Lösung zusätzlich verbessert werden kann. Auf diese Weise erhöht ein Bieter seine Chancen bei der Auswahlentscheidung zwischen verschiedenen Angeboten. Erhält er den Zuschlag, ist er verpflichtet, die von ihm zugesagten Anforderungen zur Barrierefreiheit ebenfalls umzusetzen.
Als B-Kriterien berücksichtigt werden können (nur) Anforderungen, die in der Leistungsbeschreibung nicht schon als A-Kriterien enthalten sind. Werden einige Erfolgskriterien der WCAG mit der Konformitätsstufe AAA in der Leistungsbeschreibung verbindlich als A-Kriterien festgelegt, können nur noch die übrigen Erfolgskriterien mit der Konformitätsstufe AAA im Rahmen eines Bewertungskriteriums berücksichtigt werden.
Auch aus anderen Standards und Richtlinien (z. B. DIN EN ISO 9241-110, DIN EN ISO 9241-112, DIN EN ISO 9241-125) können sich weitere Anforderungen ergeben, deren Übernahme zur Verbesserung der Barrierefreiheit dienlich sind.
Elektronische Dokumente müssen so erstellt oder erzeugt werden, dass sie barrierefrei sind. Hierzu müssen die Anforderungen aus Abschnitt 10 der EN 301 549 zur Barrierefreiheit von Dokumenten eingehalten werden. Dokumente im Format PDF müssen zusätzlich die Anforderungen aus der DIN ISO 14289-1 (PDF/UA-Standard) einhalten.
Eingesetzte Formatwandler müssen zugleich sicherstellen, dass vorhandene Informationen zur Barrierefreiheit beim Umwandlungsprozess erhalten bleiben und die Barrierefreiheit nicht verloren geht. Diese Anforderungen sind auch dann zu beachten, wenn die Konvertierung von PDF zu PDF erfolgt.
Für IT-Lösungen, die dazu bestimmt und geeignet sind, elektronische Dokumente (z. B. im Wege einer Textverarbeitung) zu erstellen, ist sicherzustellen, dass auch die so erzeugten elektronischen Dokumente die Anforderungen an die Barrierefreiheit erfüllen.
a) Formulierungsvorschlag (A-Kriterium)
Alle von der IT-Lösung erstellten Dokumente müssen den Anforderungen der EN 301 549, Abschnitt 10 (Nicht-Web-Dokumente) entsprechen.
Soweit es sich um von der IT-Lösung erzeugte PDF-Dokumente handelt, müssen diese außerdem dem PDF/UA-Standard gemäß DIN ISO 14289-1 entsprechen.
Außerdem ist für den Fall der Langzeitarchivierung sicherzustellen, dass Dokumente im Format PDF neben den Anforderungen aus dem Standard DIN ISO 19005-2a oder DIN ISO 19005-3a auch die Anforderungen an die Barrierefreiheit (DIN ISO 14289-1 und Abschnitt 10 der EN 301 549) erfüllen.
Zur Barrierefreiheit gehört auch, dass elektronische Dokumente, die im Wege des ersetzenden Scannens aus Papierdokumenten erstellt werden, für blinde und sehbeeinträchtigte Menschen mit assistiven Technologien zugänglich und lesbar sein müssen.
Elektronische Dokumente, die im Wege des ersetzenden Scannens (z. B. nach der TR-RESISCAN) in die elektronische Akte übernommen werden, müssen auch für blinde und sehbeeinträchtigte Nutzer mit assistiven Technologien barrierefrei zugänglich und nutzbar sein. Deshalb ist sicherzustellen, dass beim Einscannen von Papierdokumenten neben einer Texterkennung (OCR) auch eine Layout-Erkennung stattfindet und beim Speichern im Format PDF die erforderlichen Informationen zur Barrierefreiheit übernommen werden. Hierfür sind von besonderer Bedeutung:
Wiedergabe von Text als Zeichenfolge
Zugänglichkeit für assistive Technologien
Vorhandensein von Standardstrukturelementen (Tags) in den Dokumenten
Korrekte Spracheinstellung
Textstrukturen (wie Absätze, Überschriften, Listen und Tabellen) sowie Layout-Strukturen (wie Kopf- und Fußzeilen sowie Seitenleiste)
Sachgerechte Reihenfolge der Informationen
Erkennen von Nicht-Text-Informationen (z. B. Bilder und Grafiken) und deren Beschriftung
Navigierbarkeit des Dokuments durch Verzeichnisse und Lesezeichen
Die Texterkennung muss alle gängigen Maschinenschriften (keine Handschriften) auch bei unterschiedlicher Qualität weitgehend fehlerfrei erkennen können und das Ergebnis als
Zeichen in Unicode String Latin
an korrekter Position hinter dem Image (sodass Markieren und Entnehmen möglich wird)
ohne überflüssige Leerzeichen innerhalb von Wörtern
im ausgegebenen PDF-Dokument speichern. Der erkannte Text muss sowohl zur Recherche (Volltextsuche) als auch für assistive Technologien geeignet sein.
Die Zeichenerkennungsquote darf bei den vom Auftraggeber mitgelieferten Musterdokumenten nicht schlechter als 95 Prozent und soll möglichst 98 Prozent oder besser sein.
Die Strukturerkennung muss Absätze und Seiten erkennen und auszeichnen. Dabei sind alle Textinhalte zumindest in Absätze (Tag <p>) zu strukturieren, d. h. sofern Überschriften, Listen und Tabellen nicht anhand der Formatierung als solche erkannt werden können, sind sie zumindest als Absätze zu strukturieren. Die Seitenstruktur und die Lesereihenfolge innerhalb einzelner Textblöcke sowie die Lesereihenfolge der Hauptinhalte muss dabei erhalten werden.
Die Strukturerkennung soll erkennen:
Layout-Bereich (z. B. Briefkopf oder Seitenleiste)
Überschriften
Kopf-/Fußzeilen
Aufzählungen und Listen
Textspalten und Tabellen
Verzeichnisse (z. B. Inhalts-, Tabellen- und Abbildungsverzeichnisse)
Links und URLs
Grafiken, Bilder und mathematische Formeln
Formulare
Sprache (auch für optionale Inhalte)
und durch entsprechende Standard-Strukturelemente (Tags, siehe DIN ISO 14289-1 – PDF/UA-Standard) kennzeichnen. Kopf- und Fußzeilen sind (entgegen der DIN ISO 14289-1) nicht als Artefakte zu kennzeichnen, da sie ansonsten für assistive Technologien nicht erfassbar sind und sich in einer E-Akte nicht ausschließen lässt, dass sich in Kopf- oder Fußzeilen relevante Inhalte befinden.
Das Erkennen der Layout-Bereiche ist eine Voraussetzung für den Aufbau einer sinnvollen Textabfolge in Form eines Strukturbaums. Dies erleichtert sowohl die Zugänglichkeit für beeinträchtigte Menschen als auch die Entnahme von Texten.
Elektronische Dokumente, die im Wege des ersetzenden Scannens aus Papierdokumenten erstellt werden, werden so weit mit Strukturinformationen ergänzt, wie dies maschinell nach dem Stand der Technik möglich ist. Hierbei ist die DIN ISO 14289-1 (PDF/UA-Standard) zu beachten.
Der Formulierungsvorschlag ist je nach Auftragsgegenstand anzupassen oder zu ergänzen.
In die Leistungsbeschreibung ist aufzunehmen, dass die Anforderungen an die Barrierefreiheit über die gesamte Vertragslaufzeit erfüllt werden müssen, also auch bei Versionswechseln (wie beispielsweise bei Überarbeitungen, Aktualisierungen und Erweiterungen) sowie bei Wartung und Pflege der ausgeschriebenen IT-Lösung.
Für die Bieter kann es schwierig sein, den zusätzlichen Aufwand abzuschätzen, der sich aus der Aktualisierung von gesetzlichen Vorschriften und Standards zur Barrierefreiheit ergibt. Dennoch müssen die öffentlichen Stellen jederzeit eine barrierefreie IT-Lösung entsprechend der jeweils aktuellen Regelungen bereitstellen. Eventuell muss präzisiert werden, wo die Grenzen einer solchen Leistungspflicht liegen.
Wesentliche Voraussetzung für eine erfolgreiche Verwirklichung von Barrierefreiheit ist, dass die Anforderungen zur Barrierefreiheit von Beginn an bei der Planung und Entwicklung konsequent und umfassend berücksichtigt werden. Gleichzeitig ist sicherzustellen, dass die Barrierefreiheit einen unverzichtbaren Teil der Maßnahmen zur Qualitätssicherung bildet. Hierzu ist die Barrierefreiheit ausdrücklich im Entwicklungsprozess zu verankern.
Eine wesentliche Voraussetzung für die Verwirklichung von Barrierefreiheit ist, dass bei der Entwicklung von Beginn an eine Oberflächenbibliothek verwendet wird, deren UI-Elemente barrierefrei sind. Die Erfahrung zeigt, dass Barrierefreiheit wesentlich besser erreicht werden kann, wenn von Anfang an sichergestellt wird, dass alle verwendeten UI-Elemente barrierefrei sind. Wichtig ist, dass schon die Oberflächenbibliothek barrierefreie Komponenten zur Verfügung stellt und eine barrierefreie Oberflächengestaltung ermöglicht.
In der Praxis gibt es verschiedene Vorschläge, wie dieses Ziel erreicht werden kann.
Der Auftragnehmer ist verpflichtet für die Entwicklung der IT-Lösung eine Oberflächenbibliothek zu verwenden, die die in der Leistungsbeschreibung genannten Anforderungen zur Barrierefreiheit umsetzt und einhält.
Hierbei sind für die Einzelkomponenten die Vorgaben in der Handreichung „Barrierefreie Gestaltung von User Interface-Elementen“ (https://handreichungen.bfit-bund.de/barrierefreie-uie/), die der Leistungsbeschreibung als Anlage beigefügt ist, zu beachten.
Sofern die Bibliothek neben Komponenten auch Kompositionen aus mehreren UI-Elementen enthält, dann müssen auch diese barrierefrei sein.
Die Handreichung ist als Zusammenfassung und Überblick zu verstehen, die die für die UI-Elemente einzuhaltenden Anforderungen zur Barrierefreiheit – ohne Anspruch auf Vollständigkeit - beschreibt und erläutert, und ersetzt nicht die Einhaltung der in der Leistungsbeschreibung genannten Normen und Standards zur Barrierefreiheit in der jeweils aktuellen Fassung.
Der Auftragnehmer ist verpflichtet, dem Auftraggeber vor deren Verwendung geeignete Nachweise zur Barrierefreiheit der UI-Elemente vorzulegen.
Sinnvoll ist der Einsatz von automatisierten Entwicklungswerkzeugen, die die Entwickler bei der Programmierung unterstützen, indem sie den Code der zu nutzenden UI-Elemente automatisiert generieren.
Hierdurch wird sichergestellt, dass die in der Oberflächenbibliothek definierten UI-Elemente an allen Stellen einheitlich und in gleicher Qualität verwendet werden.
Außerdem ist es einfacher, nachträgliche Anpassungen von UI-Elementen in die gesamte IT-Lösung zu übernehmen.
Der Auftragnehmer ist verpflichtet, als Oberflächenbibliothek für die Entwicklung der IT-Lösung, die auf Webtechnologie basiert, die Komponentenbibliothek „KoliBri“ zu verwenden, die als EUROPEAN UNION PUBLIC LICENCE v1.2 Open Source zur Verfügung steht (https://public-ui.github.io/).
KoliBri dient dem Ziel die Vorgaben der Handreichung „Barrierefreie Gestaltung von User Interface-Elementen“ (https://handreichungen.bfit-bund.de/barrierefreie-uie/0.2/) umzusetzen und deren Einhaltung sicherzustellen.
Der Auftraggeber übernimmt weder Gewähr noch Haftung, dass KoliBri die in der Leistungsbeschreibung aufgeführten Anforderungen zur Barrierefreiheit vollständig erfüllt.
Sollten Komponenten dieser Bibliothek nicht vollständig barrierefrei sein, muss der Auftragnehmer den Auftraggeber darauf hinweisen und gegebenenfalls eine barrierefreie Komponente entwickeln.
Sollten einzelne Komponenten noch nicht in der KoliBri-Bibliothek enthalten sein, so soll der Auftragnehmer diese Komponenten als Beitrag zur Open-Source-Software entwickeln und der KoliBri-Bibliothek entsprechend der Lizenzbedingungen zur Verfügung stellen.
Das ITZBund verwendet für die Entwicklung von IT-Lösungen, die auf Webtechnologie basieren, die Komponentenbibliothek „KoliBri“, die als EUROPEAN UNION PUBLIC LICENCE v1.2 Open Source zur Verfügung steht (https://public-ui.github.io/).
Der Formulierungsvorschlag ist gegebenenfalls um technische Details zu der verwendeten Komponentenbibliothek zu ergänzen. Bei Verwendung von KoliBri wird das Design mittels Theming einmalig entwickelt und kann in verschiedenen IT-Lösungen wiederverwendet werden. Wenn bereits ein „KoliBri-Theme“ vorhanden ist, ist die Formulierung um die Pflicht des Auftragnehmers auf Nutzung dieses mitzuliefernden „Themes“ zu ergänzen. Ist noch kein „KoliBri-Theme“ vorhanden, sollte der Auftragnehmer zur Entwicklung und Lieferung des „Themes“ verpflichtet werden.
Die Verwendung der Komponentenbibliothek Kolibri bietet eine höhere Gewähr für die Verwirklichung von Barrierefreiheit und sichert die digitale Souveränität des Auftraggebers.
Der Auftragnehmer ist verpflichtet, für die Entwicklung der IT-Lösung die Komponentenbibliothek „… [Hier die Bezeichnung der Komponentenbibliothek eintragen] …“ zu verwenden, die dem Auftragnehmer von dem Auftraggeber zur Verfügung gestellt wird.
Die Komponentenbibliothek des Auftraggebers dient dem Ziel, die Vorgaben der Handreichung „Barrierefreie Gestaltung von User Interface-Elementen“ (https://handreichungen.bfit-bund.de/barrierefreie-uie/) umzusetzen und deren Einhaltung sicherzustellen.
Bei der Weiterentwicklung und Pflege der Komponentenbibliothek des Auftraggebers wird darauf geachtet, dass die Anforderungen zur Barrierefreiheit eingehalten und umgesetzt werden.
Sollten Komponenten dieser Bibliothek nicht vollständig barrierefrei sein, muss der Auftragnehmer den Auftraggeber darauf hinweisen und gegebenenfalls eine barrierefreie Komponente entwickeln.
Sollten einzelne Komponenten noch nicht in der Komponentenbibliothek enthalten sein, muss der Auftragnehmer diese Komponenten für den Auftraggeber entwickeln und die Komponentenbibliothek entsprechend ergänzen.
Die Formulierung kann an die eigenen Bedarfe und Voraussetzungen angepasst werden. Der Formulierungsvorschlag ist gegebenenfalls um technische Details zu der verwendeten Komponentenbibliothek zu ergänzen. Der Vorteil einer solchen Vorgehensweise ist, dass der Auftraggeber eine einmal entwickelte barrierefreie Oberflächenbibliothek einschließlich der Vorgaben zum Design auch für die Entwicklung weiterer IT-Lösungen verwenden kann. Die Verantwortung bleibt in der Hand des Auftraggebers. Aufwand und Kosten entstehen nur einmal. Die Verwendung der Komponentenbibliothek des Auftraggebers bietet eine höhere Gewähr für die Verwirklichung von Barrierefreiheit und sichert die digitale Souveränität des Auftraggebers
Die besten Ergebnisse zur Barrierefreiheit lassen sich erzielen, wenn entwicklungsbegleitend beraten und getestet und schon während der Entwicklungszeit bei Mängeln nachgesteuert wird. Daher sollte der Auftragnehmer in der Leistungsbeschreibung verpflichtet werden, schon während der Entwicklungszeit Prüf- und Testergebnisse vorzulegen und vorhandene Mängel konsequent zu beseitigen.
Der Auftragnehmer ist verpflichtet, durchgängig entwicklungsbegleitende Prüfungen und Tests zur Barrierefreiheit durchzuführen. Um die Einhaltung der Anforderungen zur Barrierefreiheit sicherzustellen, werden von Beginn an insbesondere die folgenden Prüfungen und Reviews durchgeführt:
Reviews der Design-Entwürfe und der geplanten Oberflächengestaltung (Styleguide)
Prüfung der UI-Elemente der Programmbibliothek
Prüfung der in den einzelnen Entwicklungsabschnitt (z.B. Sprints) entwickelten Komponenten und Funktionalitäten
Prüfung von Hilfe-Funktionen und Benutzerhandbüchern
Gegenstand der entwicklungsbegleitenden Prüfungen (Review, Test, …) sind auch die vollständige Tastaturbedienbarkeit und die Nutzbarkeit mit assistiven Technologien (Screenreader, Screenmagnifier, Sprachsteuerung). Die Ergebnisse der Prüfungen sind jeweils zu dokumentieren. Nach jedem Entwicklungsabschnitt (z. B. Sprint) ist ein eigener Bericht zu erstellen. Die Berichte sind dem Auftraggeber vorzulegen.
Die entwicklungsbegleitenden Prüfungen und Tests sind Bestandteil der Qualitätssicherung für den Bereich der Barrierefreiheit. Je nach Vorgehensmodell und Zeitplänen für die Lieferung von Teil-Leistungen ist der Formulierungsvorschlag um weitere Prüfgegenstände und Prüfschritte (z. B. umfassende Prüfung mit assistiven Technologien) zu ergänzen. Bei einer agilen Entwicklung ist die Einhaltung der Anforderungen zur Barrierefreiheit in die „definition of done“ aufzunehmen. Fertige Teillieferungen sind einer ausführlichen Prüfung zu unterziehen.
Werden (Teil-)Zahlungen des Auftraggebers an den Auftragnehmer an Meilensteine geknüpft, die einen bestimmten Lieferumfang, eine bestimmte Zielerreichung oder eine bestimmte Qualität definieren, ist auch die Umsetzung der Barrierefreiheit in die Zahlungsvoraussetzungen aufzunehmen.
Nutzungstests durch Menschen mit unterschiedlichen Beeinträchtigungen, z. B. durch blinde Nutzer mit einem Screenreader (einschließlich Braillezeile und Sprachausgabe), durch sehbeeinträchtigte Nutzer mit einem Screenmagnifier (Bildschirmlupe mit ergänzender Sprachausgabe) oder durch motorisch eingeschränkte Nutzende mit einem Programm zur Navigation und Steuerung über Sprachbefehle, geben wichtige Einblicke für die Verwirklichung von Barrierefreiheit. Allein die Einhaltung der Anforderungen aus den Standards zur Barrierefreiheit) reicht häufig nicht aus, um sicherzustellen, dass sich eine IT-Lösung auch mit assistiven Technologien effizient und effektiv nutzen lässt (Usability). Hier geben Nutzungstests, die auch den Workflow einbeziehen, wichtige Hinweise für die Verwirklichung von Barrierefreiheit.
Der Auftragnehmer ist verpflichtet, entwicklungsbegleitende Tests zur Usability durchzuführen, an denen Menschen mit unterschiedlichen Beeinträchtigungen und verschiedenen assistiven Technologien (Screenreader, Screenmagnifier, Sprachsteuerung) teilnehmen.
Die Tests zur Usability sind in regelmäßigen Abständen durchzuführen und sollen sich ausgehend von den mit der IT-Lösung zu erledigenden Aufgaben an den bereits erstellten Geschäftsprozessen orientieren. Gegenstand der Usability-Tests ist in der Regel der vollständige Workflow. Die Ergebnisse der Usability-Tests sind bei der weiteren Entwicklung der IT-Lösung zu berücksichtigen. Die Usability-Tests dienen dem Ziel, die Barrierefreiheit weiter zu verbessern. Die Ergebnisse der Usability-Tests sind jeweils in einem Bericht zu dokumentieren. Die Berichte sind dem Auftraggeber zusammen mit den aufgrund der Tests vorgesehenen Verbesserungen vorzulegen.
Der Formulierungsvorschlag kann ergänzt werden, indem die einzubeziehenden Nutzergruppen und die Zahl der Probanden je Nutzergruppe sowie die verwendeten assistiven Technologien (z. B. JAWS, NVDA, ZoomText, SuperNova, Dragon Naturally Speaking) benannt werden. Außerdem ist festzulegen, in welchen zeitlichen Abständen Nutzungstests durchzuführen sind (z. B. beginnend nach Erstellung der ersten Inkremente und vor der Fertigstellung einer jeden (Teil-)Leistung.
Wenn die Leistungsbeschreibung entwicklungsbegleitende Maßnahmen zur Sicherstellung der Barrierefreiheit nicht schon als A-Kriterien enthält (vgl. 3.2.1 und 3.2.2), sollte dem Auftragnehmer aufgegeben werden, hierzu ein Konzept vorzulegen.
In diesem Konzept ist vom Bieter für den gesamten Herstellungsprozess von der Entwurfsplanung über die Entwicklung bis zur Fertigstellung darzustellen, wie die Umsetzung und Einhaltung der in der Leistungsbeschreibung festgelegten Anforderungen zur Barrierefreiheit von ihm sichergestellt wird und welche Maßnahmen zur Qualitätssicherung hinsichtlich der Barrierefreiheit vorgesehen sind.
Zusammen mit dem Angebot ist ein Konzept zur Sicherstellung der Barrierefreiheit vorzulegen. In dem Konzept ist für den gesamten Herstellungsprozess, von der Entwurfsplanung über die Entwicklung bis zur Fertigstellung darzustellen, wie die Umsetzung und Einhaltung der in der Leistungsbeschreibung festgelegten Anforderungen zur Barrierefreiheit sichergestellt wird und welche weiteren Maßnahmen der Qualitätssicherung (abgesehen von dem abschließenden Gutachten zur Barrierefreiheit) hinsichtlich der Barrierefreiheit vorgesehen sind.
Im Einzelnen ist z. B. für IT-Fachanwendungen in dem Konzept darzustellen, durch welche technischen, organisatorischen und personellen Maßnahmen
die vollständige Bedienbarkeit der IT-Lösung per Tastatur und Shortcuts,
die individuelle Einstellbarkeit von Größe von Schrift und Symbolen sowie Farben und Kontrasten,
die durchgängige Nutzbarkeit mit einem Screenmagnifier (Bildschirmlupe mit ergänzender Sprachausgabe) einschließlich Fokusverfolgung und Schriftglättung,
die uneingeschränkte Nutzbarkeit und Bedienbarkeit mit einem Screenreader (einschließlich Braillezeile und Sprachausgabe) und
die durchgängige Bedienbarkeit einer Spracheingabesoftware
in der zu entwickelnden IT-Lösung durchgängig sichergestellt wird.
Die Wertung des Konzepts zur Sicherstellung der Barrierefreiheit erfolgt in Anlehnung an das Schulnotensystem mit 0 bis 5 Punkten. Dabei bedeuten
0 Punkte (ungenügend):
Die in dem Konzept beschriebene Vorgehensweise hat inakzeptable inhaltliche, strukturelle oder logische Schwächen. Das ist beispielsweise der Fall, wenn in den Ausführungen auf die in dem Bewertungskriterium genannten Aspekte nicht eingegangen wird oder der Konzeptentwurf nicht umsetzbar ist.
1 Punkt (mangelhaft):
Die in dem Konzept beschriebene Vorgehensweise hat sehr große inhaltliche, strukturelle oder logische Schwächen. Das ist beispielsweise der Fall, wenn in den Ausführungen auf die meisten in dem Bewertungskriterium genannten Aspekte nicht oder nicht nachvollziehbar eingegangen wird oder bzgl. der praktischen Umsetzbarkeit des Konzeptes erhebliche Zweifel bestehen.
2 Punkte (ausreichend):
Die in dem Konzept beschriebene Vorgehensweise hat große inhaltliche, strukturelle oder logische Schwächen. Das ist beispielsweise der Fall, wenn in den Ausführungen auf einige der in dem Bewertungskriterium genannten Aspekte nicht oder nicht nachvollziehbar eingegangen wird oder große Zweifel an der praktischen Umsetzbarkeit des Konzeptes bestehen.
3 Punkte (befriedigend):
Die in dem Konzept beschriebene Vorgehensweise hat punktuell inhaltliche, strukturelle oder logische Schwächen. Das ist beispielsweise der Fall, wenn in den Ausführungen auf viele der in dem Bewertungskriterium genannten Aspekte nachvollziehbar eingegangen wird oder bzgl. der praktischen Umsetzbarkeit des Konzeptes manche Zweifel bestehen.
4 Punkte (gut):
Die in dem Konzept beschriebene Vorgehensweise ist größtenteils schlüssig dargestellt und hat nur sehr wenige inhaltliche, strukturelle oder logische Schwächen. Das ist beispielsweise der Fall, wenn in den Ausführungen auf die meisten der in dem Bewertungskriterium genannten Aspekte nachvollziehbar eingegangen wird und bzgl. der praktischen Umsetzbarkeit des Konzeptes keine wesentlichen Zweifel bestehen.
5 Punkte (sehr gut):
Die in dem Konzept beschriebene Vorgehensweise ist schlüssig und vollständig dargestellt und lässt keine Schwächen erkennen. In den Ausführungen wird auf alle der in dem Bewertungskriterium genannten Aspekte nachvollziehbar eingegangen und es bestehen keine Zweifel an der praktischen Umsetzbarkeit des Konzeptes.
Bei Bedarf können die Inhalte, zu denen ein Bieter in dem vorzulegenden Konzept Stellung nehmen soll, um weitere Aspekte und Maßnahmen ergänzt werden. Die Bewertung nach dem Schulnotenmodell ist ein Beispiel für eine mögliche Bewertungsmatrix. Außerdem ist eine Gewichtung im Verhältnis zu den übrigen Bewertungskriterien vorzunehmen.
Die Auflistung ist auf den Auftragsgegenstand und auf die potenziellen Nutzergruppen anzupassen.
Zu den Anforderungen an die Barrierefreiheit der auszuschreibenden IT-Lösung gehört auch, dass die von dem Auftragnehmer zu erstellenden Dokumente (einschließlich der Produktdokumentation, der Benutzerhandbücher und der Hilfe-Funktionen sowie der sonstigen Unterlagen) barrierefrei sein müssen.
In die Leistungsbeschreibung ist daher auch aufzunehmen, dass auch Hilfe-Funktionen, Benutzerhandbücher und Schulungsunterlagen barrierefrei sein müssen, unabhängig davon, ob sie als Teil der IT-Lösung oder separat zur Verfügung gestellt werden. Erforderlich ist auch, dass die vorhandenen Tastaturbefehle, einschließlich der Short-Cuts, vollständig dokumentiert und Nutzereinstellungen, beispielsweise zur Größe von Schrift und Symbolen, sowie zu Farben und Kontrasten erläutert werden.
Je nach Art der Hilfe-Funktion, der Benutzerhandbücher und der Schulungsunterlagen sind die Anforderungen anzupassen oder zu ergänzen.
Außerdem ist in die Leistungsbeschreibung aufzunehmen, dass auch alle anderen zum Lieferumfang gehörenden Dokumente, einschließlich der Projekt- und Produktdokumentation und der vorzulegenden Testberichte, barrierefrei sein müssen.
Die Liefergegenstände können um weitere Dokumente ergänzt werden. Hierzu können auch Dokumente gehören, die während der Projektlaufzeit erstellt werden (z.B. Präsentationen, Protokolle und Meilensteinpläne).
In den Ausschreibungs- und Vergabeunterlagen ist auch festzulegen, wie und durch wen der Nachweis der Barrierefreiheit zu erbringen ist: durch den Auftragnehmer, durch den Auftraggeber oder durch eine unabhängige Prüfstelle. In jedem Fall ist sicherzustellen, dass die zur Begutachtung und Prüfung von IT-Lösungen (Desktop- und Web-Anwendungen) auf Barrierefreiheit erforderlichen Kenntnisse und Erfahrungen vorhanden sind . Erfahrungen lediglich bei der Prüfung von Auftritten und Angeboten im Internet (Webinhalte) reichen hierfür nicht aus.
Die Barrierefreiheit von IT-Lösungen setzt weit mehr voraus als nur die Konformität mit den in der Leistungsbeschreibung zu benennenden Standards und Regelwerken. In den Blick zu nehmen sind auch Gebrauchstauglichkeit und Nutzerfreundlichkeit (Usability). Die Begutachtung einer IT-Lösung auf Barrierefreiheit muss deshalb auch konkrete Nutzungsszenarien (Workflows) einbeziehen.
In dem Gutachten zur Barrierefreiheit ist zum einen der Nachweis zu erbringen, dass die in der Leistungsbeschreibung als A-Kriterien benannten Anforderungen zur Barrierefreiheit in der ausgeschriebenen IT-Lösung konsequent umgesetzt wurden und ausnahmslos eingehalten werden. Festzustellen ist für jede einzelne Anforderung, ob sie erfüllt, nicht erfüllt oder nur teilweise erfüllt wird. Die Gründe hierfür sind zu dokumentieren. Gleichzeitig ist in den Ausschreibungs- und Vergabeunterlagen festzulegen, dass bei der Begutachtung festgestellte Fehler und Barrieren vor der Abnahme beseitigt werden.
Der Auftragnehmer ist verpflichtet, zum Nachweis der Barrierefreiheit der von ihm entwickelten IT-Lösung einen ausführlichen Prüfbericht zur Konformität der IT-Lösung mit den in der Leistungsbeschreibung festgelegten Anforderungen zur Barrierefreiheit vorzulegen. Für jede einzelne Anforderung zur Barrierefreiheit ist darzulegen, ob sie „erfüllt“, „teilweise erfüllt“ oder „nicht erfüllt“ ist. Soweit eine Anforderung „nicht erfüllt“ oder nur „teilweise erfüllt“ ist, sind die festgestellten Fehler und Barrieren zu dokumentieren. Anforderungen zur Barrierefreiheit, für die es keinen Anwendungsbereich in der IT-Lösung gibt, sind als „nicht anwendbar“ zu kennzeichnen. Die Einstufung als „nicht anwendbar“ ist zu begründen.
Die Prüfung der Konformität der IT-Lösung mit den in der Leistungsbeschreibung festgelegten Anforderungen zur Barrierefreiheit muss sich auf die gesamte IT-Lösung beziehen. Soweit Dienste oder Komponenten Dritter (z. B. Anbringen einer qualifizierten elektronischen Signatur, elektronische Bezahlverfahren) vom Auftragnehmer in die IT-Lösung eingebunden wurden, sind diese Teile in die Prüfung der Konformität einzubeziehen. Gegenstand der Prüfung sind auch die Hilfe-Funktion und die Benutzerhandbücher.
Fehler und Barrieren, die im Rahmen der Prüfung festgestellt werden, sind vor der Abnahme zu beseitigen.
Soweit die IT-Lösung Funktionen bereitstellt, die die Erstellung von Dokumenten oder eine Formatwandlung (z. B. von einem Quell-Dokument in das Format PDF) ermöglichen, ist auch zu prüfen, ob die erstellten Dokumente den in der Leistungsbeschreibung festgelegten Anforderungen an barrierefreie Dokumente entsprechen.
Für vom Auftraggeber vorab definierte Use Cases und User Stories, die die mit der IT-Lösung zu erbringenden Aufgaben exemplarisch abbilden, ist die Funktionalität unter Verwendung von assistiven Technologien zu prüfen. Festgestellte Fehler und Barrieren sind zu dokumentieren.
Hierzu ist in den Ausschreibungs- und Vergabeunterlagen festzulegen, dass die Prüfung mit mindestens einem Screenreader, einem Vergrößerungsprogramm mit ergänzender Sprachausgabe und einer Software für die Steuerung durch Spracheingabe durchzuführen ist.
Der Auftragnehmer ist verpflichtet, neben dem Prüfbericht zur Konformität mit den in der Leistungsbeschreibung festgelegten Anforderungen zur Barrierefreiheit einen Prüfbericht zur Nutzung der IT-Lösung mit assistiven Technologien vorzulegen. Die Prüfung ist mit mindestens einem Screenreader, mindestens einem Screenmagnifier (Bildschirmlupe mit ergänzender Sprachausgabe) und mindestens einem Programm zur Steuerung über Sprachbefehle durchzuführen.
Für vom Auftraggeber vorab definierte Use Cases und User Stories, die die mit der IT-Lösung zu erbringenden Aufgaben exemplarisch abbilden, ist die Funktionalität unter Verwendung assistiver Technologien zu prüfen. Festgestellte Fehler und Barrieren sind zu dokumentieren.
Der Auftraggeber stellt dem Auftragnehmer die für die Prüfung zu verwendenden Testfälle für die zu erledigenden Aufgaben vor der Prüfung zur Verfügung.
Fehler und Barrieren, die im Rahmen der Prüfung festgestellt werden, sind vor der Abnahme zu beseitigen.
Der Formulierungsvorschlag kann präzisiert werden, indem die an den Arbeitsplätzen der Beschäftigten eingesetzten assistiven Technologien unter Angabe der jeweiligen Produktbezeichnung genannt werden.
Für das Betriebssystem Windows gängige Screenreader sind bspw. JAWS und NVDA, gängige Vergrößerungsprogramme mit ergänzender Sprachausgabe bspw. ZoomText und SuperNova.
Für das Betriebssystem macOS und iOS sind gängige Screenreader und -maginifier VoiceOver und Zoom
Für das Betriebssystem Android ist der gängige Screenreader TalkBack
Als Programm zur Sprachsteuerung werden bspw. Dragon Naturally Speaking oder Betriebssystem-eigene Funktionen eingesetzt.
für das Betriebssystem Linux gängige Screenreader bspw. Orca (Open Source) und SpeakUp (Open Source)
Use Cases und User Stories sind anhand des Auftragsgegenstandes vom Auftraggeber zu definieren. Die Anzahl der Use Cases und User Stories ist in der Ausschreibungsunterlage festzulegen. Falls der Auftraggeber eigene Testpersonen für die definierten Use Cases und User Stories bereitstellt, sollte festgelegt werden, dass auch in diesem Szenario festgestellte Fehler und Barrieren vor der Abnahme behoben werden.
Zusätzlich zu den Prüfergebnissen zur Konformität mit den Anforderungen aus der Leistungsbeschreibung sowie der Use Cases sind Inhalt und Umfang der Dokumentation der Prüfergebnisse festzulegen.
Die Prüfungen zur Barrierefreiheit sind jeweils in einem Prüfbericht schriftlich zu dokumentieren. Diese enthalten insbesondere folgende Angaben:
Nennung des Prüfgegenstandes inklusive Versionsnummer
Nennung und Verweis auf das verwendete Prüfverfahren
Bezeichnung der geprüften Komponenten und Bestandteile der IT-Lösung (einschließlich Version und Datum der geprüften Entwicklungsstände)
Gegenstand und Umfang der Prüfung, Beschreibung der Testfälle und der Prüf-Szenarien
Testumgebung und Testbedingungen
Verwendete Prüfwerkzeuge und Prüftools
Verwendete assistive Technologien (Name und Version)
Zeitraum und Ort der Prüfung
Name der beteiligten Testenden
Detaillierte Wiedergabe des Prüfergebnisses
Bei festgestellten Fehlern und Barrieren werden in dem Bericht soweit möglich Vorschläge formuliert, wie sich die Anforderungen zur Barrierefreiheit umsetzen lassen.
Die Prüfberichte werden ihrerseits in einem barrierefreien Format (Einhaltung der Anforderungen der EN 301 549, Abschnitt 10, und der DIN ISO 14289-1) vorgelegt.
Falls eigene Vorlagen für die Dokumentation von Ergebnissen oder ein Ticket-System verfügbar sind, kann der Auftragnehmer verpflichtet werden, diese zu verwenden.
Die Leistungsbeschreibung gehört zum Kernbereich der Ausschreibungs- und Vergabeunterlagen, da hier die Anforderungen an den Leistungsgegenstand festgelegt werden. Anforderungen an die Barrierefreiheit, die eine IT-Lösung aufgrund der gesetzlichen Vorgaben oder aufgrund von zusätzlichen Vorgaben des Auftraggebers in jedem Fall erfüllen muss, müssen in der Leistungsbeschreibung klar und eindeutig benannt werden. Sie sind als Ausschlusskriterien (A-Kriterien) zu formulieren, da nur so ihre Einhaltung rechtlich verbindlich festgelegt wird. Um die Verwirklichung von Barrierefreiheit sicherzustellen, sollte die Leistungsbeschreibung hierzu nicht nur Anforderungen an den Leistungsgegenstand (die ausgeschriebene IT-Lösung) enthalten. Zu formulieren sind auch Anforderungen an den Entwicklungsprozess und die Dokumentation.
Zusätzlich zu A-Kriterien können weitere Gesichtspunkte zur Barrierefreiheit, die darüber hinausgehen, in der Leistungsbeschreibung im Rahmen von Bewertungskriterien (B-Kriterien) berücksichtigt werden (§ 127 Abs. 1 Satz 4 GWB, § 58 Abs. 2 Nr. 1 VgV). Ein Bieter, der bei den Bewertungskriterien gut abschneidet, kann hierdurch seine Chancen auf den Zuschlag erhöhen. Die zusätzliche Berücksichtigung der Barrierefreiheit in der Leistungsbeschreibung im Rahmen von B-Kriterien ist daher ein wichtiges Instrument, um auch hinsichtlich der Barrierefreiheit einen Wettbewerb um die beste Lösung zu erreichen. Bewertungskriterien zur Barrierefreiheit können sich sowohl auf zusätzliche Anforderungen an den Ausschreibungsgegenstand als auch auf den Entwicklungsprozess beziehen.
In der folgenden Tabelle werden die Formulierungsvorschläge aus der Handreichung aufgelistet und den Kategorien „verpflichtend", „verpflichtend, wenn anwendbar", „dringend empfehlenswert" und „sinnvoll" zugeordnet.
Die in der Tabelle vorgenommene Priorisierung stellt nur eine Empfehlung dar. Sie entbindet nicht von der Verpflichtung eigenständig zu prüfen, welche Anforderungen zur Barrierefreiheit aufgrund von gesetzlichen Vorschriften (z. B. im BGG, in der BITV 2.0 oder in Fachgesetzen) stets in die Ausschreibungs- und Vergabeunterlagen aufzunehmen sind und wie sich die Barrierefreiheit bestmöglich sicherstellen lässt.
Zu beachten ist auch, dass Anforderungen zur Barrierefreiheit, die als Ausschlusskriterien in die Leistungsbeschreibung aufgenommen werden, von dem Auftragnehmer in jedem Fall einzuhalten sind, während Anforderungen zur Barrierefreiheit, die im Rahmen von Bewertungskriterien berücksichtigt werden, von dem Auftragnehmer nur dann umzusetzen sind, wenn er dies in seinem Angebot zusagt.
| Thea | Art des Kriteriums | Kategorie | Erläuterung |
|---|---|---|---|
| Abschnitt zum Ziel der barrierefreien Gestaltung (1.) | — | dringend empfehlenswert | Verdeutlicht die Bedeutung der Barrierefreiheit für die Qualität der ausgeschriebenen IT-Lösung. |
| Vorlage von Referenzen (2.1.1) | A | sinnvoll | Dient der Eignungsprüfung eines Bieters (berufliche und fachliche Qualifikation). |
| Vorlage von Referenzen für einen Teilnehmerwettbewerb (2.1.2) | B | — | Alternative zu 2.1.1, nur bei Teilnehmerwettbewerb möglich. |
| Verankerung der Barrierefreiheit im Unternehmen (2.1.3) | B | — | Barrierefreiheit sollte zur Unternehmensstrategie gehören. |
| Software-Experte für Barrierefreiheit (2.2.1) | A | dringend empfehlenswert | Wichtig für die Sicherstellung der Barrierefreiheit. |
| Test-Experte für Barrierefreiheit (2.2.2) | A | dringend empfehlenswert | Wichtig für die Sicherstellung der Barrierefreiheit. |
| Experte für Usability (2.2.3) | A | sinnvoll | Die Berücksichtigung von Usability-Aspekten dient der Barrierefreiheit und kommt zugleich allen Nutzern zugute. |
| Standards zur Barrierefreiheit (3.1.1) | A | verpflichtend | Die Standards sind gesetzlich festgelegt und damit in jedem Fall in der Ausschreibung einzufordern. |
| Bedarfe unterschiedlicher Nutzergruppen (3.1.2) | A | sinnvoll | Zusätzliche Anforderungen potenzieller Nutzergruppen sind nach § 3 Abs. 3 BITV 2.0 stets zu berücksichtigen; der Formulierungsvorschlag benennt hierfür nur ein Beispiel. |
| Optimierung der Barrierefreiheit (3.1.3), Vorschlag 1: Tastaturkonzept | A | dringend empfehlenswert | Ein Tastaturkonzept kann die Barrierefreiheit wesentlich verbessern. |
| Optimierung der Barrierefreiheit (3.1.3), Vorschlag 2: WCAG-AAA | A | dringend empfehlenswert | Barrierefreiheit kann durch Erfolgskriterien der Konformitätsstufe AAA wesentlich verbessert werden. |
| Optimierung der Barrierefreiheit (3.1.3), Vorschlag 3: WCAG-AAA | B | — | Nur möglich, wenn nicht schon als A-Kriterium berücksichtigt. |
| Erstellung von Dokumenten (3.1.4.1) | A | verpflichtend, wenn anwendbar | Von IT-Lösungen elektronisch erstellte Dokumente müssen barrierefrei sein. |
| Ersetzendes Scannen (3.1.4.2) | A | verpflichtend, wenn anwendbar | Gescannte Dokumente müssen barrierefrei sein. |
| Barrierefreiheit während der gesamten Vertragslaufzeit (3.1.5) | A | verpflichtend | Barrierefreiheit endet nicht mit der ersten Abnahme, sondern ist während der gesamten Vertragslaufzeit erforderlich. |
| Oberflächenbibliothek (3.2.1), Vorschlag 1: User-Interface-Elemente | A | dringend empfehlenswert | Wesentliche Voraussetzung für die Verwirklichung von Barrierefreiheit. |
| Oberflächenbibliothek (3.2.1), Vorschlag 2: Komponentenbibliothek KoliBri | A | dringend empfehlenswert | Sinnvolle Alternative zu Formulierungsvorschlag 1. |
| Oberflächenbibliothek (3.2.1), Vorschlag 3: Komponentenbibliothek des Auftraggebers | A | dringend empfehlenswert | Sinnvolle Alternative zu Formulierungsvorschlag 1. |
| Entwicklungsbegleitende Tests zur Barrierefreiheit (3.2.2) | A | dringend empfehlenswert | Wesentliche Voraussetzung für die Verwirklichung von Barrierefreiheit. |
| Usability-Tests durch unterschiedliche Nutzergruppen (3.2.3) | A | sinnvoll | Wichtiger Beitrag zur Verbesserung der Barrierefreiheit. |
| Konzept zur Umsetzung der Barrierefreiheit | B | — | Mögliche Alternative, wenn 3.2.2 und 3.2.3 nicht in den Ausschreibungsunterlagen enthalten sind. |
| Hilfe-Funktionen, Benutzerhandbücher und Schulungsunterlagen (3.3.1) | A | verpflichtend | Hilfe-Funktionen und Benutzerhandbücher müssen vollständig barrierefrei sein. |
| Dokumente zum Liefergegenstand (3.3.2) | A | verpflichtend | Alle erstellten Dokumente müssen barrierefrei sein. |
| Nachweis der Konformität mit den Anforderungen zur Barrierefreiheit (4.1) | A | verpflichtend | Notwendige Grundlage für die Abnahme. |
| Nachweis der Barrierefreiheit anhand von Use Cases (4.2) | A | dringend empfehlenswert | Weitere Grundlage für die Abnahme. |
| Dokumentation der Prüfergebnisse (4.3) | A | verpflichtend | Gutachten und Prüfberichte zur Barrierefreiheit müssen vollständig und nachvollziehbar sein. |
Gesetz gegen Wettbewerbsbeschränkungen (Teil 4, insb. §§ 121 Abs. 2, 122 und 127 Abs. 1 Satz 4 GWB) https://www.gesetze-im-internet.de/gwb
Vergabeverordnung (insb. §§ 31 und 58 Abs. 2 Nr. 1 u. Nr. 2 VgV) https://www.gesetze-im-internet.de/vgv_2016
Unterschwellenvergabeordnung (insb. §§ 23 Abs. 4, 43 Abs. 2 Nr. 1 UVGO) https://www.bmwk.de/Redaktion/DE/Downloads/U/unterschwellenvergabeordnung-uvgo.pdf?__blob=publicationFile&v=1
Gesetz zur Gleichstellung von Menschen mit Behinderungen (insb. §§ 4, 12a Abs. 1 Satz 2 und Abs. 2 BGG) https://www.gesetze-im-internet.de/bgg/
Barrierefreie-Informationstechnik-Verordnung (insb. § 3 BITV 2.0) https://www.gesetze-im-internet.de/bitv_2_0
Carstens, Andreas, Barrierefreie Informationstechnik, in: Deinert, O. / Welti, F. / Luik, S. / Brockmann, J. (Hrsg.), Stichwortkommentar Behindertenrecht, Nomos Verlagsgesellschaft, 3. Aufl. 2022, S. 176 - 193
Carstens, Andreas, Die rechtliche Verpflichtung zur digitalen Barrierefreiheit, in: Peter, U. / Lühr, H.-H. (Hrsg.), Handbuch Digitale Teilhabe und Barrierefreiheit, Kommunal- und Schul-Verlag 2021, S. 37 - 79
Kirch, Thomas, Für alle gemacht – eine verpflichtende Koordinate öffentlicher Beschaffung, Vergaberecht 2017, S. 234 - 240
EN 301 549 (Version 3.2.1) Accessibility requirements for ICT products and services, European Telecommunications Standards Institute (ETSI) (Hrsg.), https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf
DIN EN 301 549 (Version 3.2.1) Barrierefreiheitsanforderungen für IKT-Produkte und -Dienstleistungen, Deutsche Fassung der EN 301 549 (Bezug über: https://www.bfit-bund.de/Login/Login/login_node.html)
DIN EN ISO 9241-110:2020-10, Ergonomie der Mensch-System-Interaktion - Teil 110: Interaktionsprinzipien (ISO 9241-110:2020); Deutsche Fassung der EN ISO 9241-110:2020 (Bezug über: www.DINMedia.de)
DIN EN ISO 9241-112:2017-08, Ergonomie der Mensch-System-Interaktion - Teil 112: Grundsätze der Informationsdarstellung (ISO 9241-112:2017); Deutsche Fassung der EN ISO 9241-112:2017 (Bezug über: www.DINMedia.de)
DIN EN ISO 9241-125:2018-05, Ergonomie der Mensch-System-Interaktion - Teil 125: Empfehlungen zur visuellen Informationsdarstellung (ISO 9241-125:2017); Deutsche Fassung der EN ISO 9241-125:2017 (Bezug über: www.DINMedia.de)
DIN EN ISO 9241-171 :2008-10, Ergonomie der Mensch-System-Interaktion - Teil 171: Leitlinien für die Zugänglichkeit von Software (ISO 9241-171:2008); Deutsche Fassung der EN ISO 9241-171:2008 (Bezug über: www.DINMedia.de)
DIN EN ISO 9241-210:2020-03, Ergonomie der Mensch-System-Interaktion - Teil 210: Menschzentrierte Gestaltung interaktiver Systeme (ISO 9241-210:2019); Deutsche Fassung der EN ISO 9241-210:2019 (Bezug über: www.DINMedia.de)
DIN ISO 14289-1:2016-12, Dokumentenmanagementanwendungen - Verbesserung der Barrierefreiheit für das Dateiformat von elektronischen Dokumenten - Teil 1: Anwendung der ISO 32000-1 (PDF/UA-1) (ISO 14289-1:2014) (Bezug über: www.DINMedia.de)
ISO 19005-2:2011-07, Dokumenten-Management - Elektronisches Dokumenten-Dateiformat für die Langzeitarchivierung - Teil 2: Anwendung der ISO 32000-1 (PDF/A-2) (Bezug über: www.DINMedia.de)
ISO 19005-3:2012-10, Dokumenten Management - Elektronisches Dokumenten-Dateiformat für die Langzeitarchivierung - Teil 3: Anwendung der ISO 32000-1 mit Unterstützung für eingebettete Dateien (PDF/A-3) (Bezug über: www.DINMedia.de)
Accessible Rich Internet Applications (WAI-ARIA) 1.2, W3C, 2023, [online], https://www.w3.org/TR/wai-aria-1.2/
Authoring Tool Accessibility Guidelines (ATAG) 2.0, W3C, 2015, [online], https://www.w3.org/TR/ATAG20/
Web Content Accessibility Guidelines (WCAG) 2.1, W3C, 2023, [online], https://www.w3.org/TR/WCAG21/
Web Content Accessibility Guidelines (WCAG) 2.1, 2022, [online], nicht autorisierte deutsche Übersetzung: https://outline-rocks.github.io/wcag/translations/WCAG21-de/
Web Content Accessibility Guidelines (WCAG) 2.2, W3C, 2023, [online], https://www.w3.org/TR/WCAG22/
Handreichung „Barrierefreie Gestaltung von User Interface-Elementen", Empfehlungen des Ausschusses für barrierefreie Informationstechnik, [online], https://handreichungen.bfit-bund.de/barrierefreie-uie
Vergabebaustein Barrierefreiheit, in: Portal Barrierefreiheit, herausgegeben vom Bundesministerium des Innern und für Heimat, 2022, [online], https://www.barrierefreiheit-dienstekonsolidierung.bund.de/Webs/PB/DE/barrierefreie_it/vergabebaustein/vergabebaustein.html
Leitfaden zur Ausschreibung barrierefreier Webseiten, veröffentlicht von der Landesfachstelle für Barrierefreiheit Sachsen-Anhalt, 2023, [online], https://www.lf-barrierefreiheit-st.de/digitales/webseiten/leitfaden-zur-ausschreibung-barrierefreier-webseiten
KoliBri - Komponentenbibliothek für die Barrierefreiheit, herausgegeben vom Informationstechnikzentrum Bund (ITZBund),[online], https://www.itzbund.de/DE/itloesungen/standardloesungen/kolibri-barrierefreie-komponentenbibliothek/kolibri.html
Diese Handreichung wird unter der Lizenz CC-BY-SA 4.0 veröffentlicht. Sie können Sie bearbeiten und unter Namensnennung und mit gleicher Lizenz weiterverbreiten. Wenn Sie Teile davon verändern, müssen Sie das entsprechend kennzeichnen.
Diese Handreichung hat die Version 1.0 und wurde am 28.05.2026 erstellt.
Die Deutsche Rentenversicherung Knappschaft-Bahn-See ist eine rechtsfähige Körperschaft des öffentlichen Rechts mit Selbstverwaltung und besitzt Dienstherrnfähigkeit (§ 29 SGB IV in Verbindung mit § 143 Abs. 1 SGB VI).
Dieses Impressum gilt für dieses Dokument der Arbeitsgruppen des Ausschusses für barrierefreie Informationstechnik nach § 5 BITV 2.0. Die Arbeitsgruppen werden von der Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik organisiert.
Deutsche Rentenversicherung Knappschaft-Bahn-See
Pieperstraße 14 - 28
44789 Bochum
Tel. 0234 304 - 0
Fax 0234 304 - 66050
E-Mail an die Zentrale der KBS: zentrale@kbs.de
Umsatzsteuer-Identifikationsnummer: DE 124089627
Dieses Dokument wird herausgegeben von der Deutschen Rentenversicherung Knappschaft-Bahn-See, vertreten durch die Geschäftsführung, Dr. Rainer Wilhelm.
Bundesministerium für Arbeit und Soziales
Wilhelmstraße 49
10117 Berlin
Die Inhalte dieser Handreichung werden mit größtmöglicher Sorgfalt verfasst. Unser Anspruch ist es, richtige, vollständige und aktuelle Inhalte bereitzustellen. Wir übernehmen dennoch keine Gewähr für versehentlich gemachte falsche Angaben.
Diese Handreichung enthält Verknüpfungen zu Webauftritten Dritter (“externe Links”). Wir haben bei der erstmaligen Verknüpfung zu externen Links die fremden Inhalte daraufhin überprüft, ob etwaige Rechtsverstöße bestehen. Zu diesem Zeitpunkt haben wir keine Rechtsverstöße vorgefunden. Wir haben jedoch weder Einfluss auf die aktuelle und zukünftige Gestaltung der verknüpften Seiten noch auf deren Inhalte oder Angebote. Sollten uns Rechtsverstöße bekannt werden, löschen wir die betreffenden externen Links unverzüglich. Bitte weisen Sie uns gegebenenfalls darauf hin.