Version: 1.0
Sie können diese Handreichung als PDF-Datei (Öffnet PDF-Dokument) oder DOCX-Datei (Öffnet Word-Dokument) herunterladen.
Für die Qualitätssicherung digitaler Barrierefreiheit können im Software-Entwicklungsprozess vielfältige Entwicklungs- und Testmethoden zum Einsatz kommen, wie die Befragung von Benutzerinnen, Dokumentreviews oder entwicklungsbegleitende Tests. Oft muss die Barrierefreiheit darüber hinaus nochmals explizit nachgewiesen werden, beispielsweise wenn digitale Produkte eingekauft, am Ende der Entwicklung abgenommen oder für den Einsatz in der Organisation freigegeben werden sollen.
Selbstauskünfte von Herstellerinnen (bspw. Voluntary Product Accessibility Template, kurz VPAT) haben sich für diesen Zweck teilweise als nicht ausreichend detailliert erwiesen, auch wenn sie oft die einzigen verfügbaren Aussagen über die Barrierefreiheit sind. In diesen Fällen kann es erforderlich sein, eine Prüfung des digitalen Produkts durchzuführen und die Ergebnisse in Gutachtenform darzustellen.
Je nach Prüfdienstleisterin können die erstellten Gutachten über die Barrierefreiheit ein unterschiedliches Erscheinungsbild haben. Für die Auftraggeberin und Empfängerin der Gutachten ist es dann von großer Bedeutung, dass sie wesentliche Inhalte und Ergebnisse in allen Dokumenten wiederfinden und eine grundlegende Vergleichbarkeit gegeben ist. Auch sollen die eventuell festgestellten Probleme sowie die Zusammenfassung greifbar und verständlich sein. Denn meist sind die Ergebnisse entscheidend für die weitere Verwendung und den Einsatz des digitalen Produkts und die Leserinnen sind nicht immer Fachexpertinnen der Barrierefreiheit.
Die Inhalte eines Gutachtens sollen zudem die Reproduzierbarkeit der Ergebnisse ermöglichen, sodass Problempunkte nachvollzogen, bewertet und behoben werden können.
Ein Gutachten der Barrierefreiheit richtet sich also in vielen Fällen an unterschiedliche Zielgruppen, deren Erfordernisse bedacht werden müssen:
Interessenvertretungen (Personalvertretungen, Schwerbehindertenvertretungen o. ä.), beratende Personen im Software-Entwicklungsprozess
Entscheiderinnen über den Einsatz, Einkauf oder die Freigabe eines digitalen Produkts
Entscheiderinnen über die durchzuführenden Maßnahmen am Prüfgegenstand
Entwicklungsteams, die die Barrierefreiheit umsetzen müssen
Diese Handreichung soll Mindestanforderungen an Gutachten über die digitale Barrierefreiheit von Informations- und Kommunikationstechnologie (kurz: IKT) darstellen. Ziel ist es, Gutachtenempfängerinnen zu unterstützen ihre Anforderungen an Gutachten zu formulieren sowie Prüfdienstleisterinnen gleiche Qualitätskriterien über diese Anforderungen bereitzustellen.
Die beschriebenen Anforderungen sind geeignet für Gutachten, die abschließende Auskunft über die digitale Barrierefreiheit eines fertigen Webauftritts, mobilen Anwendung oder einer Software geben sollen, z. B. für Abnahme nach Ende eines Entwicklungsprojektes, eines Updates oder einer Erweiterung, als Grundlage für eine Einkaufsentscheidung oder Freigabe für den Einsatz am Arbeitsplatz.
Für Testberichte, die entwicklungsbegleitend angefertigt werden, um Erkenntnisse in die Weiterentwicklung einfließen zu lassen, können die dargestellten Anforderungen als Empfehlungen angesehen werden. Je nach Entwicklungsphase ist jedoch eine Anpassung empfehlenswert.
Die Texterstellerinnen erkennen in diesem Text alle Geschlechteridentitäten an. Sie erkennen Bedarfe der Barrierefreiheit im Verstehen und Wahrnehmen an.
Daher findet bei Personenbezeichnungen oder personenbezogenen Worten die neutrale oder die weibliche Form Anwendung. Auf diese Weise soll eine möglichst gleichberechtigte und wertschätzende Sprachform Ausdruck finden, die der Individualität aller Menschen gleichermaßen begegnet.
Gutachten über die digitale Barrierefreiheit müssen mindestens folgende Angaben enthalten:
Titel
Name und Anschrift des prüfenden Unternehmens
Namen der Prüferinnen und/oder Autorinnen
Eindeutige Benennung des Prüfgegenstands, inkl. Versionsnummer
Beschreibung des Prüfgegenstands (siehe Kapitel 2.3)
Datum der Prüfung bzw. des Prüfzeitraum
Ausstellungsdatum des Gutachtens
Benennung der Prüfgrundlage (siehe Kapitel 2.2)
Aussage, dass sich die Ergebnisse nur auf den geprüften Gegenstand innerhalb des Prüfzeitraums bzw. für die jeweilige Versionsnummer beziehen
Ergebnisse (siehe auch Kapitel 2.5)
Zusammenfassung der Ergebnisse (siehe Kapitel 2.5.1)
Bewertung der Konformität mit den zugrunde gelegten Anforderungen und Standards (siehe Kapitel 2.5.2)
Problembeschreibungen (siehe Kapitel 2.5.3)
Beschreibung des Prüfumfangs (siehe Kapitel 2.4) (Teile oder Komponenten, die nicht geprüft worden sind, sollten benannt werden)
Beschreibung der Prüfmethode (siehe Kapitel 2.4.1 und Kapitel 2.4.2 insbesondere zur Nutzbarkeit mit Hilfsmitteln)
Beschreibung der Prüfumgebung (siehe Kapitel 2.6)
Beschreibung der Prüfwerkzeuge (siehe Kapitel 2.7)
Optional:
Benennung der für die Freigabe des Berichts verantwortlichen Person(en)
Namen und Kontaktdaten der Auftraggeberin
Für öffentliche Stellen gelten in Deutschland gesetzliche Vorgaben für die Umsetzung der digitalen Barrierefreiheit (siehe auch BFIT-Bund: Informationen zur Umsetzung von barrierefreier Informationstechnik im Sinne von § 3 Absatz 5 BITV 2.0 (PDF)). Die Auftraggeberin entscheidet über die jeweilige Prüfgrundlage für die Gutachtenerstellung. Vor der Beauftragung eines Gutachtens sollte jeweils geprüft werden, welche Anforderungen als Prüfgrundlage anzuwenden sind. Die prüfende Stelle (Dienstleisterin) soll der Auftraggeberin bei der Wahl der Prüfgrundlage beratend unterstützen.
Folgende Übersicht zeigt, welche Anforderungen nach der geltenden Barrierefreie- Informationstechnik-Verordnung (BITV 2.0) je Kontext und Anwendungstechnologie zu beachten sind.
| Prüfgegenstand | Standard EN 301 549 | Weitere Anforderungen gemäß BITV 2.0 bzw. je nach Landesgesetzgebung |
|---|---|---|
| Webseite oder mobile Webansicht einer öffentlichen Stelle | Anhang A Tabelle A.1 |
|
| Mobile Anwendung einer öffentlichen Stelle | Anhang A Tabelle A.2 |
|
| Nicht-Web-Dokument einer öffentlichen Stelle | Abschnitt 10 | Für PDF: DIN ISO 14289-1 (PDF/UA), gemäß Stand der Technik (§ 3 Abs. 3) |
| Software einer öffentlichen Stelle | Abschnitt 5 bis 7 und 9 bis 13, nicht nur Abschnitt 9 oder Abschnitt 11 |
|
| Hardware einer öffentlichen Stelle | Abschnitt 5-13, nicht nur Abschnitt 8 | - |
Für die Technologien Software und Hardware muss die Anwendbarkeit aller Anforderungen (Vorbedingungen gemäß EN 301 549, Anhang C) geprüft werden. Es reicht nicht aus, die Anforderungen aus einzelnen Abschnitten oder den Tabellen A.1 und A.2 im Anhang der EN 301 549 zu prüfen. Für die jeweiligen Landesgesetze zur Barrierefreiheit von Informationstechnik oder die einschlägigen Fachgesetze muss geprüft werden, ob abweichende Anforderungen einzuhalten sind. Wenn gemäß § 3 Abs. 4 BITV 2.0 ein höheres Maß an Barrierefreiheit umgesetzt werden muss oder soll, sind weitere Prüfgrundlagen wie beispielsweise das Konformitätslevel AAA der WCAG heranzuziehen. Ebenso können organisationsspezifische Regelungen und Standards sowie von der Auftraggeberin zusätzlich festgelegte Anforderungen in die Prüfung einbezogen werden. Darüber hinaus ist es empfehlenswert die Standards der Software-Ergonomie, z.B. Gebrauchstauglichkeit bzw. Usability, Normreihe DIN EN ISO 9241, zu berücksichtigen.
Der Prüfgegenstand soll so beschrieben werden, dass auch fachfremde Leserinnen das Gutachten verstehen und die Prüfergebnisse nachvollziehen können. Zur Beschreibung des Prüfgegenstands gehören die im Folgenden beschriebenen Aspekte.
Zum einen der Verwendungszweck, der Nutzungskontext sowie die Benennung der Zielgruppen und ggf. Nutzerrollen. Dies ermöglicht einen Einblick in die mit der IKT ausgeführten Tätigkeiten und Anforderungen, die Einfluss auf die Bewertung einzelner Anforderungen haben können.
Beispiele:
Eine Webseite zur Terminbuchung, die von allen Bürgerinnen sowohl am PC als auch mobil genutzt wird.
Eine Anwendung für alle Mitarbeiterinnen einer Organisation, die in der Regel am Arbeitsplatz verwendet wird, um Dienstreisen zu planen.
Eine mobile Anwendung, die nur von bestimmten Mitarbeiterinnen einer Organisation verwendet wird, um mittels Tablet Reparaturmaßnahmen am Inventar zu dokumentieren.
Zum anderen soll die Anwendungstechnologie (Web, Software, mobile Anwendungen, PDF, Excel etc.) dokumentiert werden, um die Auswahl der Prüfgrundlage zu erläutern (Anwendbarkeit der Abschnitte der EN 301 549).
Beide Aspekte haben auch Auswirkung auf die zu wählenden Prüfwerkzeuge.
Eine kurze Nennung des Testumfangs (z. B. anhand geprüfter Module, Hauptfunktionen, Beachtung von Handbuch / Hilfe) ermöglicht einen ersten Überblick, über die dargestellten Ergebnisse.
Auch die Nennung von Schnittstellen, die Teil des Geschäftsprozesses sind, kann hilfreich sein, um die Ergebnisse für Entscheiderinnen besser bewertbar zu machen.
In der Regel ist die gesamte Anwendung mit all ihren Teilen zu prüfen. Ziel ist es, den Prüfumfang so zu wählen, dass eine ausreichend hohe Testabdeckung erreicht wird, um eine fundierte Aussage bzgl. der Barrierefreiheit treffen zu können.
Der Gesamtumfang der Prüfung wird vor der eigentlichen Prüfung festgelegt. Dieser Schritt ist grundlegend, er wirkt sich auf alle folgenden Schritte aus.
Der Prüfumfang wird idealerweise in enger Absprache mit der Auftraggeberin abgestimmt, da ggf. der zukünftige Einsatz der IKT eine Rolle spielt, und um gemeinsame Erwartungen an den Umfang zu gewährleisten. Die Auftraggeberin kann festlegen, dass auch die Nutzbarkeit mit von der Auftraggeberin festgelegten Hilfsmitteln Teil der Prüfung ist, insbesondere dann, wenn bestimmte Hilfsmittel in der Organisation der Auftraggeberin genutzt werden, sollte die Nutzbarkeit mit diesen Hilfsmitteln in die Prüfung einbezogen werden.
Insbesondere für eine abschließende Prüfung mit dem Ziel der Erstellung eines Gutachtens, muss der Prüfumfang zweckmäßig gewählt werden. Einerseits sollen eventuell vorhandene Barrierefreiheitsprobleme gefunden werden, andererseits muss aber auch der Aufwand dem Zweck einer abschließenden Prüfung entsprechen.
Von einem Gutachten mit dem Ziel einer abschließenden Prüfung wird erwartet, dass es einerseits eine verlässliche Aussage zur Barrierefreiheit der geprüften IKT trifft und noch vorhandene Barrierefreiheitsprobleme auflistet. Andererseits ist eine Prüfung auf Barrierefreiheit häufig nur anhand einer repräsentativen Stichprobe möglich. Der Prüfungsumfang ist deshalb in jedem Fall mit Sorgfalt auszuwählen.
Die im Gutachten dargestellten Ergebnisse gelten dementsprechend nur für den im Gutachten beschriebenen Prüfumfang.
Einerseits müssen die gefundenen Barrierefreiheitsprobleme von der Auftraggeberin auf alle Einsätze in der IKT (eines Elements, Farbschemas, Funktion etc.) übertragen werden. Anderseits bedeuten positive, erfüllte Anforderungen nicht, dass ungeprüfte Teile der IKT immer korrekt barrierefrei umgesetzt wurden.
Um eine möglichst gute Testabdeckung zu erreichen, ist daher die Festlegung des Prüfumfangs zentral (siehe Kapitel 2.4.1 und Kapitel 2.4.3).
Hinweise:
Gutachten stellen einen Kompromiss zwischen Kosten-Nutzen-Verhältnis und Risikominimierung dar.
Es empfiehlt sich, die technischen Umsetzungsteams einer IKT mit in die Stichprobenauswahl für den Prüfumfang einzubinden. Diese haben meist den besten Überblick in die Funktionsweise, Oberflächen-/Seitentypen und die relevanten Funktionen einer Anwendung.
Die Auftraggeberin hat bei der Festlegung und Ausgestaltung des Prüfumfangs eine entscheidende Rolle. Sie hat eine Mitwirkungspflicht, und muss der Auftragnehmerin relevante Informationen zur prüfenden IKT zur Verfügung stellen, um eine effiziente Prüfung der IKT zu unterstützen.
Folgende Informationen sollte die Auftraggeberin zur Verfügung stellen:
Informationen zum Nutzungskontext der IKT
Betriebssystem(e) z. B. Windows, MacOS, Android, iOS, in denen die IKT getestet werden muss
Benennung der genutzten Browser in der Organisation (nur für Webkontext)
Benennung der Aufgaben, die mit der IKT erledigt werden sollen
Genutzte Hilfsmittel (assistive Technologie) in der Organisation
Zugangs- sowie ggf. Testdaten für die Nutzung der IKT
Dokumentation zur Tastaturnavigation der IKT (einschließlich einer Auflistung der Shortcuts)
Anwendungsdokumentation der IKT (wenn vorhanden)
Ansprechpartnerin bei der Auftraggeberin (fachlich, technisch, organisatorisch)
Zusätzliche Informationen können hilfreich oder erforderlich sein, um ein aussagekräftiges Gutachten zu erhalten:
Fachliche Informationen zur IKT
Informationen zu der (erwartenden) Nutzergruppe der IKT
Informationen zu Use Cases oder Anwendungsszenarien (z. B. konkrete Beispiele für mit der IKT zu erledigende Aufgaben, Nutzbarkeit mit einem bestimmten Hilfsmittel oder Hilfsmittel-Benutzeragent-Kombinationen)
In die Abstimmung zwischen Auftraggeberin und Auftragnehmerin sind ggf. auch die Interessensvertretungen, z. B. Schwerbehindertenvertretung, aufseiten der Auftraggeberin einzubeziehen.
Es gilt der Grundsatz einer „IKT für alle".
Barrierefreiheit dient dazu eine gleichberechtigte Teilhabe bei der Nutzung von IKT für alle zu erreichen. Die Prüfung muss daher alle potenziellen Nutzergruppen einbeziehen. Einzelne Nutzergruppen oder Nutzerszenarien dürfen in der Regel nicht von der Prüfung ausgeschlossen werden.
Bei der Bestimmung des Prüfgegenstands und der entsprechenden Arbeitsaufgabe kann es in Abstimmung mit der Auftraggeberin bzw. den Interessensvertretungen zu Abgrenzungen für bestimmte Nutzergruppen oder Nutzungsszenarien kommen. Nutzerinnen mit Beeinträchtigungen sind in den Entscheidungsprozess einzubeziehen.
Ein bestimmter Hilfsmitteleinsatz sowie Arbeitseinsatz/-situation für den Prüfgegenstand kann vorgegeben oder auch ausgeschlossen werden. Der Ausschluss kann nur aufgrund von bestimmten körperlichen Voraussetzungen für Arbeitsaufgaben begründet werden.
Abgrenzungen bestimmter Nutzergruppen in Bezug auf die Arbeitsaufgabe sollten im Prüfbericht nachvollziehbar erläutert werden.
Beispiel für den sinnvollen Ausschluss eines Nutzungsszenarios: Die Nutzung einer vorwiegend visuell-basierten Software zum Lotsen von Flugzeugen am Himmel oder auf dem Rollfeld durch blinde oder stark sehbeeinträchtigte Personen.
Beispiel für keine gültige Abgrenzung / Ausschluss: Die Nutzung einer Software durch blinde Nutzerinnen wird vom Prüfumfang ausgeschlossen, weil aktuell keine blinden Nutzerinnen in der Organisation mit dieser Software arbeiten.
In einem ersten Schritt soll der Umfang der IKT definiert werden. Im Kontext einer Website-Prüfung wird nachfolgend der Begriff „Seite“ benutzt, um eine einzelne Webseite oder einen Bildschirm innerhalb eines Webauftritts (Website) bzw. eine Dialogmaske innerhalb einer mobilen Anwendung oder Software zu bezeichnen.
Es kann dabei auch wichtig sein, bestimmte Aspekte der Zielwebsite zu dokumentieren, die als Abgrenzung oder Erweiterung des Prüfumfangs anzusehen sind, wie
die Nutzung von Inhalten und Diensten Dritter;
mobile Versionen und verschiedene Sprachversionen;
Teile der IKT, die möglicherweise nicht ohne weiteres als solche erkennbar sind, weil sie bspw. eine andere Webadresse hat oder eine separate IKT ist, die aber jeweils als Teil der zu prüfenden Anwendung anzusehen sind.
Eine Abgrenzung nicht geprüfter Anwendungsbereiche kann zusätzlich sinnvoll sein (siehe auch Kapitel 2.4.2).
Im zweiten Schritt sollen die konkret zu prüfenden Seiten dokumentiert werden. Für Webseiten kann dies in Form von URLs erfolgen, insofern diese statisch sind, also keine Parameter enthalten. Für dynamische URLs sowie Software und mobile Anwendungen muss eine andere Form der Dokumentation gewählt werden (z. B. Navigationspfade, Klickanleitung).
Für die Auswahl einer Stichprobe für eine informationsorientierte Website eignet sich die im Durchführungsbeschluss (EU) 2018/1524 zur Festlegung einer Überwachungsmethodik und der Modalitäten für die Berichterstattung empfohlene Auswahl:
Startseite (Home), Anmeldung (Login), Site-Übersicht (Sitemap), Kontakt, Hilfe und Seiten mit rechtlichen Informationen;
zumindest eine relevante Seite für jede Art von Dienst, der von der Website oder mobilen Anwendung bereitgestellt wird, und für jeden anderen Hauptzweck, einschließlich der Suchfunktion;
die Seiten mit der Erklärung oder den Angaben zur Barrierefreiheit sowie die Seiten mit dem Feedback-Mechanismus;
beispielhaft ausgewählte Seiten mit einem deutlich anderen Erscheinungsbild oder anderen Arten von Inhalten;
zumindest ein relevantes abrufbares Dokument, falls vorhanden, für jede Art von Dienst, der von der Website oder mobilen Anwendung bereitgestellt wird, und für jeden anderen Hauptzweck;
nach dem Zufallsprinzip ausgewählte Seiten im Umfang von mindestens 10 % der festgelegten Stichprobe.
Diese Stichprobenauswahl richtet den Fokus vor allem auf informationsorientierte Webseiten, wie Webauftritte öffentlicher Stellen, insofern diese keine Prozessschritte beinhalten.
Insbesondere für Fachanwendungen (bspw. elektronisch unterstützte Verwaltungsabläufe, Verfahren zur elektronischen Vorgangsbearbeitung, elektronischen Aktenführung) und andere prozessorientierte IKT oder prozessorientierte Teilbereiche von Websites (wie Anmelde- oder Bestellprozesse, Online-Umfragen etc.) müssen vollständige Prozesse und damit verbundene Aufgaben geprüft werden. Die Stichprobe für die Prüfung muss sämtliche Grundfunktionalitäten der Anwendung enthalten. Für wiederkehrende Aufgaben oder Funktionen kann eine repräsentative Auswahl getroffen werden.
Für webbasierte Fachanwendungen ist auch die in Kapitel 2.4.3.1 vorgestellte Methodik zur Auswahl der Stichprobe anzuwenden, so dass der Prüfumfang nicht dahinter zurückbleibt.
Seiten oder grafische Oberflächen mit unterschiedlichen Stilen, Layouts, Strukturen und Funktionen bieten häufig unterschiedliche Unterstützung für die Barrierefreiheit. Sie werden oft von verschiedenen Vorlagen und Skripten generiert oder von verschiedenen Personen erstellt. Deshalb müssen die unterschiedlichen Oberflächentypen/Seitentypen im Prüfumfang enthalten sein.
Oberflächentypen/Seitentypen, aus denen eine repräsentative Auswahl getroffen werden kann, können sein:
mit unterschiedlichen Stilen, Layout, Struktur, Navigation, Interaktion und visuellem Design
mit unterschiedlichen Arten von Inhalten wie Formularen, Tabellen, Listen, Überschriften, Multimedia und Skripten
mit unterschiedlichen Funktionskomponenten wie Datumsauswahl, Lightbox, Schieberegler und anderen
mit Verwendung verschiedener Technologien wie HTML, CSS, JavaScript, WAI-ARIA, PDF usw.
mit unterschiedlichen Vorlagen erstellt (sofern bekannt)
die von verschiedenen Personen, Abteilungen und anderen Entitäten erstellt wurden (sofern bekannt)
die das Erscheinungsbild und Verhalten je nach Benutzerin, Gerät, Browser, Kontext und Einstellungen ändern
mit dynamischen Inhalten, Fehlermeldungen, Dialogfeldern, Popup-Fenstern und anderen Interaktionen
Im Prüfumfang muss die (Produkt-)Dokumentation (sofern vorhanden) enthalten sein (vgl. EN 301 549 Abschnitt 12).
Der Prüfumfang muss eine strukturierte Stichprobe aus jeder der genannten Kategorien enthalten:
Allgemeine Seiten-/Oberflächen
Essenzielle Funktionalitäten
Unterschiedliche Oberflächen- bzw. Seitentypen
Seiten, die für Menschen mit Beeinträchtigungen relevant sind (Hilfe, Barrierefreiheitsfunktionen oder Erläuterungen dazu, Kontaktinformationen etc.)
Produktdokumentation
Ergänzend soll eine zufällige Stichprobe von 10 % der strukturierten Stichprobe enthalten sein.
Die EN 301 549 verweist ergänzend auf die Konformitätsanforderungen der WCAG 2.1. Diese fordern zum einen die Prüfung ganzer Seiten und zum anderen die Prüfung vollständiger Prozesse.
Es ist also bspw. nicht zulässig nur den Inhaltsbereich einer Webseite zu prüfen und Kopf- oder Fußzeile auszulassen. Ebenso darf in einem Bestellprozess nicht nur die Seite mit dem Warenkorb geprüft werden. Vielmehr muss der gesamte Bestellprozess bis zum Abschluss betrachtet werden.
Die Methodik zur Bewertung der Konformität der Barrierefreiheit von Websites (WCAG-EM) 1.0 (Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0) definiert Web-Anwendungen als expliziten Anwendungsbereich, bezieht also prozessorientierte Anwendungen explizit ein. Das dort beschriebene Vorgehen (WCAG-EM Schritt 1) kann dementsprechend sowohl auf mobile Anwendungen als auch auf Software-Anwendungen übertragen werden.
Die Darstellung der Prüfergebnisse orientiert sich am Zweck des Gutachtens. Wenn möglich sollen die Ergebnisse in verschiedene Ausgabeformate übertragen werden können.
Das Begutachtungsdokument muss selbst barrierefrei gemäß EN 301 549 Abschnitt 10 sein, sollte es sich um ein PDF-Dokument handeln, ist zudem der PDF/UA-Standard DIN ISO 14289-1 einzuhalten.
Die Zusammenfassung des Gutachtens muss Entscheidungsträgerinnen sowie Gremienvertreterinnen die Möglichkeit geben, die Barrierefreiheit der IKT einzuschätzen und Maßnahmen für den Einsatz, den Einkauf oder die Optimierung der IKT zu planen. Sie muss deshalb für alle Leserinnen leicht verständlich sein und soll nicht in technischer Sprache geschrieben sein. Denn nicht alle Leserinnen haben Wissen in Bezug auf die geprüfte IKT oder die digitale Barrierefreiheit.
Die Zusammenfassung soll deshalb eine Gesamtbewertung über die Erfüllung der Prüfgrundlage (BITV 2.0, EN 301 549, WCAG etc.) (siehe Kapitel 2.2) geben. Sie muss es erlauben, zu erkennen, wie viele Anforderungen bestanden bzw. nicht bestanden sind (Konformität bzw. Vereinbarkeit) und wie gut die IKT von Menschen mit Beeinträchtigungen genutzt werden kann (Benutzbarkeit bzw. Zugänglichkeit). Hierbei ist nach unterschiedlichen Benutzergruppen zu unterscheiden (vgl. EN 301 549 Abschnitt 4.2 Aussagen zur Funktionalität).
Die Gesamtbewertung zum Stand der Barrierefreiheit darf dabei nicht als Punktwert oder Prozentangabe dargestellt sein.
Zu beachten ist auch, dass das Wort „barrierearm“ weder gesetzlich definiert, ist noch den gesetzlichen Anforderungen an die Barrierefreiheit genügt. Es ist damit kein tauglicher Begriff für eine Begutachtung und soll im Bericht nicht verwendet werden.
Sofern im Kontext der IKT sinnvoll, soll die Gesamtbewertung je Nutzungsszenario, Benutzerrolle oder Anwendungsbereich erfolgen.
Insbesondere für Interessensvertretungen (z. B. Schwerbehindertenvertretungen, Personalvertretungen) auf Seite der Auftraggeberin sollten relevante Informationen wie die Angabe von Arbeiten / Tätigkeiten/Teile der Software, die für Menschen mit Beeinträchtigungen bzw. unter Nutzung bestimmter Hilfsmittel nicht möglich sind, angegeben werden.
Aus der Zusammenfassung muss sich ergeben, welche Mängel in der IKT behoben werden müssen, da das Gutachten auch Grundlage für zu treffende Maßnahmen- und Zeitpläne zur Umsetzung nicht bestandener Anforderungen sein wird.
Ergeben sich aus der Prüfung Probleme der Barrierefreiheit, die sich nutzungsverhindernd auswirken (Blockaden), müssen diese in der Zusammenfassung benannt werden.
Nach Möglichkeit soll aus der Zusammenfassung ersichtlich sein, welche Änderungen (z. B. Verbesserung oder Verschlechterung) sich zu einer vorangegangenen Begutachtung ergeben.
Die Übersicht stellt alle Anforderungen der Prüfgrundlage in einer Übersichtstabelle dar. Aus der Tabelle ist mindestens ersichtlich, welche Anforderungen bestanden, nicht bestanden und/oder nicht anwendbar oder nicht prüfbar sind. Zu Bestimmung des Prüfumfang und Abgrenzung siehe auch Kapitel 2.3.
Die Gesamtanzahl der Anforderungen, die bestanden, nicht bestanden und/oder nicht anwendbar oder nicht prüfbar sind, muss jeweils auf einfache Weise erkennbar sein.
Für die weitergehende Einschätzung der Barrierefreiheit ist die Beschreibung der festgestellten Probleme wichtig. Sie erlaubt es den Entscheiderinnen und den Gremienvertreterinnen einzuschätzen, wie schwerwiegend eventuelle Probleme sind.
Für Herstellerin und Entwicklerin der IKT muss die Problembeschreibung nachvollziehbar darstellen, wo die Probleme sind und Anhaltspunkte für deren Behebung liefern.
Die Problembeschreibung muss mindestens folgendes enthalten:
Verweis auf die nicht bestandene Anforderung gemäß EN 301 549
Bewertung der Anforderung (bspw. „nicht bestanden")
siehe auch EN 301 549 Abschnitt 14 Konformität zu Ergebnissen von Tests gemäß Anhang C:
nicht anwendbar,
bestanden,
nicht bestanden
oder (in Ausnahmefällen) nicht prüfbar
Zuordnung des betreffenden Personenkreises gemäß EN 301 549 Anhang B Zusammenhang zwischen den Anforderungen und den Aussagen zur funktionalen Leistungsfähigkeit
Zusammenfassung der elf funktionellen Leistungsfähigkeiten ist möglich
Transparente Darstellung der Zusammenfassung der Gruppen
Mindestens Primärer Zusammenhang, sekundärer Zusammenhang nur bei expliziter Relevanz
die Beschreibung der Nutzbarkeit mit vorher festgelegten assistiven Technologien (sofern von der Auftraggeberin gefordert)
Die Problembeschreibung soll folgendes enthalten:
eine Priorisierung oder Klassifikation, die es erlaubt, die Schwere des Barrierefreiheitsproblems einzuschätzen und ggf. eine Priorisierung für die Behebung zu erstellen,
das Problemvorkommen (Wo/Wann tritt das Problem auf?), um das Problem reproduzieren zu können (Beschreibung des Testfalls).
Hinweis: Gefundene Probleme sind nur Beispiele aus der geprüften Stichprobe. Diese müssen auf nicht geprüfte Teile der IKT übertragen werden, wenn dort ähnliche Elemente, Farbschemata, Funktionen etc. genutzt werden.
Die Problembeschreibung kann ergänzend einen oder mehrere der folgenden Aspekte enthalten:
die Problemursache (sofern nachvollziehbar);
die Auswirkung des Problems auf die Nutzung; dabei ist zu beachten, dass sich die Nicht-Erfüllung der Anforderungen nach Art der Nutzung ganz unterschiedlich auswirken kann. Je nach Art der Einschränkung kann der vorgesehene Workflow sich einschränkend oder behindernd bzw. verhindernd für Menschen mit Beeinträchtigungen auswirken;
einen oder mehrere Screenshots, die das Problem illustrieren;
Lösungsvorschläge (bspw. falls eine Weiterentwicklung geplant ist), die das erwartete Verhalten der IKT beschreiben oder, sofern möglich, Empfehlungen auf Code-Ebene geben (bspw. basierend auf der Publikation [BFIT-Bund: Barrierefreie Gestaltung von User Interface-Elementen);
die Berücksichtigung der Benutzerrollen (z. B. Barrieren in einer Admin-Rolle mit geringer Anzahl);
ggf. darüberhinausgehende Hinweise.
Zu empfehlen ist, dass die Auftraggeberin bei der Beauftragung des Gutachtens festlegt, worauf im Rahmen der Problembeschreibung einzugehen ist (siehe in diesem Kapitel aufgeführte Listen).
Es wird empfohlen zusätzlich zum Prüfbericht eine Mängelliste bereitzustellen, welche bspw. eine einfache Übernahme in ein Ticketsystem ermöglicht. Hierzu eignen sich generell strukturierte Formate wie XML oder CSV.
Das Gutachten muss die Prüfumgebung genau beschreiben, um reproduzierbar und transparent gefundene Probleme bzw. bestandene Anforderungen darzustellen. Dazu zählen:
Genutzte Hardware (falls spezielle Parameter gefordert sind, z. B. spezielle Eingabegeräte oder -methodik);
Software-Ausstattung (z. B. Betriebssystem, Bildschirmauflösung, Sicherheitssoftware und Zugriffsart z. B. Terminal-Server);
Versionen von Browsern oder anderer Software, die zum Ausführen (z. B. JAVA) genutzt wird.
Im Gutachten muss erläutert werden, welche Prüfwerkzeuge und Hilfsmittel durch die Prüferin eingesetzt wurden, um die Anforderungen an die Barrierefreiheit gemäß Prüfgrundlage zu prüfen.
Teil der Prüfung sollten nicht nur Hilfsmittel/assistive Technologien unterteilt nach Hard- und Software (mit Versionsstand) sein, sondern ggf. auch direkt Prüfwerkzeuge (z. B. Accessibility Insights) auf die Barrierefreiheitsschnittstelle (Accessibility API). Die verwendeten Prüfwerkzeuge zum Auslesen der Barrierefreiheitsschnittstelle sind mit Versionsstand zu benennen.
Dabei ist wichtig, dass die eingesetzten Prüfwerkzeuge zur Client-/Server-Architektur der zu prüfenden Anwendung passen (Web- oder Desktop-Clients). Es können auch automatisiert oder teil-automatisierte Test-Tools oder auch Browser-Tools eingesetzt werden. Diese sind dann ebenfalls mit Versionsstand aufzuführen.
Die fachliche Expertise der durchführenden Personen (Barrierefreiheitsprüferin oder Gutachterin) hat erheblichen Einfluss auf die Qualität der Gutachten. Daher sollten nur entsprechend qualifizierte und geschulte Personen entsprechende Barrierefreiheitsprüfungen durchführen und Gutachten erstellen.
Die Barrierefreiheitsprüferin oder Gutachterin sollte über folgende Kenntnisse verfügen:
Kenntnisse relevanter Verordnungen, Normen und Richtlinien zur Barrierefreiheit, u. a.
BITV 2.0
EN 301 549
WCAG
PDF/UA
Kenntnisse zu den Nutzergruppen mit Beeinträchtigungen (vergleiche auch EN 301 549 Abschnitt 4 Funktionale Anforderungen)
Kenntnis und Verständnis von Code (u. a. HTML, JavaScript, WAI-ARIA, PDF-Tagging)
Kenntnisse zum Umgang mit assistiven Technologien (Hilfsmitteln) sowie Nutzung von Software durch Nutzergruppen mit Beeinträchtigungen wie
per Tastatur und Shortcuts,
mit einem Screenmagnifier (Bildschirmlupe, mit ggf. ergänzender Sprachausgabe),
mit einem Screenreader (einschließlich Braillezeile und Sprachausgabe) sowie
mittels einer Sprachsteuerungssoftware.
Die Barrierefreiheitsprüferin oder Gutachterin sollte darüber hinaus über folgende praktische Erfahrungen verfügen:
Mehrjährige Erfahrungen als Test-Expertin für Barrierefreiheit bei der Begutachtung und dem Testen von Desktop-Anwendungen (Software) und Web-Anwendungen (IT-Fachanwendungen) auf Barrierefreiheit.
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 PDF/UA, DIN ISO 14289-1)
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. Ggf. sind die assistiven Technologien namentlich durch die Auftraggeberin zu benennen, für die Kenntnisse und Erfahrungen gefordert werden.
Mehrjährige Mitarbeit bei der Planung und Entwicklung von IT-Lösungen als Test-Expertin und Beraterin für Barrierefreiheit.
Die Kenntnisse und Erfahrungen sind der Auftraggeberin vor der Auftragserteilung durch geeignete Dokumente (z. B. Zertifizierungen der IAAP sowie ISTQB, Referenzprojekte, Lebenslauf) nachzuweisen.
Beispielsweise ist der Nachweis über die Expertise zur Prüfung von Web-Auftritten kein geeigneter Nachweis zur Expertise für die Prüfung von Software.
Um eine gleichbleibend hohe Qualität von Gutachten gewährleisten zu können, müssen bei den Dienstleisterinnen entsprechende Prozesse zur internen Qualitätssicherung etabliert sein.
Nachweise für die intern durchgeführten Maßnahmen der Qualitätssicherung können sein:
Aussagekräftige Beschreibung des Qualitätssicherungsprozesses z. B. mit Erläuterungen zu fortlaufender Verbesserung von Prozessen und Arbeitsabläufen, kontinuierlicher Weiterbildung von Mitarbeitenden, strukturierten Arbeitsprozesse, dokumentierten Zielen und Strukturen
Ggf. Vorlage geeigneter Zertifikate der Dienstleisterin bezogen auf den zu vergebenden Auftragsgegenstand (z. B. DIN EN ISO 9001:2015-11 Qualitätsmanagementsysteme, ISO/IEC 25051:2014 Software-Engineering - System- und Software-Qualitätsanforderungen und Evaluation (SQuaRE) - Qualitätsanforderungen an Ready to Use Software (RUSP) und Prüfverfahren, DIN EN ISO/IEC 17025:2018-03 Allgemeine Anforderungen an die Kompetenz von Prüf- und Kalibrierlaboratorien)
Anzahl durchgeführter Prüfungen in einem bestimmten Zeitraum bezogen auf den Prüfgegenstand des Gutachtens (z. B. Webauftritte, Dokumente, Software, mobile Anwendungen)
Website Accessibility Conformance Evaluation Methodology (WCAG-EM) 1.0 (w3c.org)
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
Testen von digitaler Barrierefreiheit (bundesfachstelle-barrierefreiheit.de)
Portal Barrierefreiheit: Prüfen (barrierefreiheit-dienstekonsolidierung.bund.de)
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 24.06.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.