2. Berichtsform und -inhalte

Für öffentliche Stellen gelten in Deutschland gesetzliche Vorgaben des Bundes und der Länder für die Umsetzung der digitalen Barrierefreiheit (siehe auch zum Beispiel BFIT-Bund: Informationen zur Umsetzung von barrierefreier Informationstechnik im Sinne von § 3 Absatz 5 BITV 2.0 (PDF)).

Der Auftraggeber 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. Der Prüfdienstleister soll den Auftraggeber 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.

Unterstützend kann auch der [Standardanforderungskatalog](Standardanforderungskatalog https://www.barrierefreiheit-dienstekonsolidierung.bund.de/Webs/PB/DE/standardanforderungskatalog/standardanforderungskatalog-node.html) der Dienstekonsolidierung hinzugezogen werden. Dieser bildet nicht in jedem Fall alle heranzuziehenden Prüfgrundlagen ab.

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.

Bei der Beauftragung eines Gutachtens ist darauf zu achten, dass die einzuhaltenden technischen Standards und Normen in ihrer jeweils geltenden Fassung zu Grunde gelegt werden. Weitere Anforderungen, die sich aus Aktualisierungen oder Überarbeitungen der Standards ergeben, wie bspw. bei der WCAG 2.2, können zusätzlich als Prüfmaßstab zu Grunde gelegt werden, auch wenn sie noch nicht rechtlich verbindlich sind. In diesen Fällen ist es erforderlich die weiteren zu beachtenden Anforderungen konkret zu benennen.

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. Dabei ist darauf zu achten, dass die zusätzlich zu prüfenden Anforderungen ausdrücklich benannt werden.

Ebenso können organisationsspezifische Regelungen und Standards sowie vom Auftraggeber 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. Diese gehen über die vorgenannten Regelungen hinaus, haben sich aber als sinnvoll erwiesen.

Der Prüfgegenstand soll so beschrieben werden, dass auch fachfremde Lesende 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.

• Eine Webseite zur Terminbuchung, die von allen Bürgerinnen und Bürgern sowohl am PC als auch mobil genutzt wird
• Eine Anwendung für alle Mitarbeitenden einer Organisation, die in der Regel am Arbeitsplatz verwendet wird, um Dienstreisen zu planen
• Eine mobile Anwendung, die nur von bestimmten Mitarbeitenden 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.

Bei der Festlegung des Prüfumfangs ist zu berücksichtigen, dass dieser aussagefähig für die Barrierefreiheit der gesamten Anwendung sein muss. Soweit sich der Prüfumfang auf Stichproben beschränkt, ist zwingend erforderlich eine nachvollziehbare repräsentative Auswahl zu treffen. Eine Abnahmeerklärung unter Nichtberücksichtigung von Barrierefreiheit kann sich zu einem späteren Zeitpunkt als problematisch erweisen.

Der Auftraggeber sollte daher Vorkehrungen treffen, die sicherstellen, dass auch Mängel zur Barrierefreiheit, die erst nachträglich bekannt werden, vom Hersteller zu beheben sind.

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 durch den Auftraggeber festgelegt. Die Festlegung erfolgt in enger Abstimmung mit dem Auftragnehmer. Im Rahmen seines Prüfauftrags schlägt der Auftragnehmer ergänzende Stichproben vor. Der Auftraggeber kann festlegen, dass auch die Nutzbarkeit mit von dem Auftraggeber festgelegten Hilfsmitteln Teil der Prüfung ist. Insbesondere dann, wenn bestimmte Hilfsmittel in der Organisation des Auftraggebers 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 vom Auftraggeber 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.3).

Hinweis: Es empfiehlt sich, die technischen Umsetzungsteams einer IKT, die Fachseite und die Gremien mit in die Stichprobenauswahl für den Prüfumfang einzubinden.

Der Auftraggeber hat bei der Festlegung und Ausgestaltung des Prüfumfangs eine entscheidende Rolle. Er muss dem Auftragnehmer alle relevanten Informationen zur prüfenden IKT zur Verfügung stellen, um eine effiziente Prüfung der IKT zu unterstützen.

Folgende Informationen muss der Auftraggeber 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)
• Ansprechperson beim Auftraggeber (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 (erwarteten) 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 Auftraggeber und Auftragnehmer sind ggf. auch die Interessensvertretungen, z. B. Schwerbehindertenvertretung, aufseiten des Auftraggebers 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 dem Auftraggeber bzw. den Interessensvertretungen zu Abgrenzungen für bestimmte Nutzergruppen oder Nutzungsszenarien kommen. Nutzende 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 Nutzende wird vom Prüfumfang ausgeschlossen, weil aktuell keine blinden Nutzenden 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 haben oder eine separate IKT sind, 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 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 alle relevanten Funktionalitäten der Anwendung enthalten. Hierbei kann für wiederkehrende Aufgaben oder Funktionen 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.

Eine repräsentative Auswahl kann beispielsweise getroffen werden aus Oberflächentypen / Seitentypen:

• 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. 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) (Website Accessibility Conformance Evaluation Methodology (WCAG-EM) ) 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ägern sowie Gremienvertretungen 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 Lesenden leicht verständlich sein und soll nicht in technischer Sprache geschrieben sein. Denn nicht alle Lesenden haben Wissen in Bezug auf die geprüfte IKT oder die digitale Barrierefreiheit.

Die Zusammenfassung sollte 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 des Auftraggebers müssen 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 Entscheidern und den Gremienvertretungen einzuschätzen, wie schwerwiegend eventuelle Probleme sind.

Für Hersteller und Entwickler 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 vom Auftraggeber 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 der Auftraggeber 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 gefundene Probleme bzw. bestandene Anforderungen reproduzierbar und transparent 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 den Prüfdienstleister 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) zum Auslesen der 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 zu der zu prüfenden Anwendung passen (Web- oder Desktop-Clients). Es können auch automatisierte oder teil-automatisierte Test-Tools oder auch Browser-Tools eingesetzt werden. Diese sind dann ebenfalls mit Versionsstand aufzuführen.

Informationen zu diesem Artikel

Datum:

16.07.2026

Lizenz:

CC-BY-SA 4.0

Version:

2.0

Gerne können Sie uns Feedback per E-Mail zu unserer Handreichung senden!