2. Berichtsform und -inhalte

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.

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.

Informationen zu diesem Artikel

Datum:

17.03.2025

Lizenz:

CC-BY-SA 4.0

Version:

1.0

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